Design Debt

I’ve just been reading some of James Shore‘s articles, and was very impressed. The article on Design Debt is a good attempt to explain why a particular approach is a long-term disaster.

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.

This site uses Akismet to reduce spam. Learn how your comment data is processed.