Programmers will often complain that a piece of code needs to be rewritten. As far as management are concerned, the code works perfectly well, and granting the programmers’ requests would bring no benefit.
The quality of a piece of code depends on more than its ability to pass given tests, although that is a sine qua non. Even after being put into production, a piece of code will be changed many times, and worked on by many people. It should therefore be easy to understand and easy to change.
What makes something easy to understand? Most of this is obvious: ease of reading (good formatting), value-adding comments, good choice of variable names. I think that the value of a sensible naming convention for code blocks is higher than most people think – you should be able to look at the name of a block of code and know straight away what it does.
James Shore uses an analogy with interest on a loan to explain the cost of design debt. Incurring the debt gives you something now, seemingly for nothing. Until that something is repaid in full however, there is a constant leak of resources.
From my own experience, this leak of experience takes a few important forms. The most noticable is the difficulty of grasping the purpose and function of an unfamiliar piece of code. Evaluating code for side-effects is also more difficult when it is under-designed. Code with an outstanding design debt may repeat itself in places. This makes changing the way it works a trial, as every repetition must be changed the same way.
The solution to design debt is refactoring. It doesn’t have to be XP-style merciless refactoring, but it has to be done, or development slows down under the weight of poor design. If the refactoring isn’t folded into a development project, then it may require a project of its own in order to get done. On the other hand, project managers may not look well on programmers taking on redesign work outside the scope of the project at hand.