Code size is a problem of in software engineering. Some people even think it is the most important problem we have.
But it is not code size alone. You may not be working on a mammoth code base, but code size may still be a problem. Being more precise, excess of code is always a problem. Obviously, it is worse on enormous and intractable system, but it is painful everywhere.
Today I experimented this by trying to rename a bunch of methods of a class. The class was in the DAO layer of an application with at least two layers on top of it: EJBs and “business delegates”. As the rename method refactor does not work through delegation, find and replace was better suited for my particular case. It comes with the price of checking that the search pattern does not occur in other places. I was luck and the pattern was not found elsewhere, so it was cheap and far less tiresome than repeating every rename operation three or four times.
I think it is a bit ironic how some program's source seem to be made to work against the tools, almost like on purpose. Java programs tend to be massive and verbose, basically for cultural reasons, but also as a consequence of the limitation of the language. Big codebases were born and typical text editors fell short.
To fix this, wonderful IDEs have emerged. They allow us to browse the mess we create, and to create more of it. As modifying the mess came to be a major problem, refactoring tools came to the rescue and were integrated into the IDEs.
Today, I stare at the pointless layers of this system and see how they defeat many automatic refactors. Not only rename method, but also push down, pull up and maybe others. Maybe, in the future, some refactors will detect delegation and work through it.
I will not deny the usefulness of such improvement if it happens, but I am pretty sure that they are solving the wrong problem. Code excess is the problem. Pointless layers “just if some day we want do it in another way” are the problem. Violating DRY is the problem. Not realizing that YAGNI is the problem.
In the end, it seems like a people problem, backed by technology.