Ok, I accept this. I have experience in refactoring really bad code. Refactoring these always led to smaller code: yes sometimes some of the refactorings increased the code size, but there was enough redundancy because of the bad (or no) abstractions and design mistakes in the original code which compenstated for it.
The bigger the system is, the more probable it is that you can make it better while decreasing the code size. Above 10.000 lines a bad code usually is not DRY enough so much, that it is very easy to decrease its size while increasing its modularity.
Yes, code size is not a perfect indicator of quality. But reducing code size is a very central part of my design philosophy. When you very conciously refactor to smaller code size (using good design patterns) the code and the abstractions in your head can become incredibily clear.
For example I write a software which deals a lot with rectangles. In the beginning my rectangles had four properties: left, right, top, bottom. After a while I've found out that my code gets more and more redundant; I have to find an abstraction which relies on the symmetries in the problems. So now my rectangle has this interface to get and set the 4 sides:
void setSide(bool vert, bool isEnd, int value)
int getSide(bool vert, bool isEnd)
Not only my code size reduced dramatically, but because of this new abstraction I've understood the problem much better!
The bigger the system is, the more probable it is that you can make it better while decreasing the code size. Above 10.000 lines a bad code usually is not DRY enough so much, that it is very easy to decrease its size while increasing its modularity.
Yes, code size is not a perfect indicator of quality. But reducing code size is a very central part of my design philosophy. When you very conciously refactor to smaller code size (using good design patterns) the code and the abstractions in your head can become incredibily clear.
For example I write a software which deals a lot with rectangles. In the beginning my rectangles had four properties: left, right, top, bottom. After a while I've found out that my code gets more and more redundant; I have to find an abstraction which relies on the symmetries in the problems. So now my rectangle has this interface to get and set the 4 sides:
void setSide(bool vert, bool isEnd, int value)
int getSide(bool vert, bool isEnd)
Not only my code size reduced dramatically, but because of this new abstraction I've understood the problem much better!