Design Debt

Internal software quality is important as it has a direct impact on the cost of further software development. Good software design saves money even in small-scale development projects. Design debt refers to future development costs resulting from poor software structure.

A typical example of incurring design debt is when you want to quickly introduce an additional software feature. An investigation reveals that implementing the new function would require extensive changes to the existing source code and database structure. Since you may not want to embark on a major revision for the sake of a single add-on feature, you come up with a shortcut, such as copying the source code with minor changes for the new function. Implementing a new feature in this way—at the expense of the software structure – incurs design debt, since any subsequent changes in the same parts of the software will now be more costly than if you had chosen a different approach. With regard to future development costs, it would have made more sense to split the existing code and implement the new feature using the available bits of code.

Cheap is Expensive

Programmers and the project manager or customer often disagree on the feasibility of solutions involving a different workload. Often it is a case of choosing between a more expensive method and incurring design debt. The programmer presents a more elegant, labor-intensive solution and a faster, corner-cutting option. If the faster option incurs design debt, the actual total cost for long-term software will nevertheless exceed that of the debt-free option. The “interest” on design debt comprises higher further development costs due to symptoms of rotting design and their multiplier effect (see sidebar).

Software design is often project-based. From the perspective of a single project, taking on design debt in order to stay on schedule and within budget may be tempting. Debt is often incurred in the final crunch phase of a project, sub-project or iteration. Should the software be developed further or should identified errors be fixed after the project has been closed, any previously accumulated debt becomes due at this stage. Resolving the conflict between short-term and long-term objectives requires the much-discussed expertise in IT purchasing. It should also be noted that, even within a single iteration, the interest on the design debt may consume any profit made by taking on the debt.

Improving the Design is Worthwile

The most efficient way to manage design debt is by continuously improving the design whenever you make changes or fix bugs. If you have accumulated design debt, either inadvertently or on purpose, you should pay it off early to avoid incurring excessive interest on the debt. Usually, the most efficient way to do this is by refactoring the design in conjunction with functional changes or bug fixes to the code when the same code needs to be changed anyway.

You may also have to allocate time for clean up. Extensive, automated regression tests significantly facilitate design improvements. The tests also offer a convenient method for verifying software functionality after refactoring or other cleaning.

At worst, taking on design debt may lead to the software becoming completely unfit for any further development. In this case, rewriting the software from scratch may seem the only viable option. Such rewrite projects are extremely expensive and risky. You need to maintain the old software throughout the entire rewrite project. During this phase, any changes to the software must be implemented in both versions. If the new software accumulates too much design debt, this may lead to a vicious circle of rewrites that may last for years.

Design debt is more ambiguous and more difficult to measure than monetary debt, which makes it difficult to control. Objectively measuring the design quality is only possible to a limited extent, for example by calculating dependencies between modules. In practice, however, the evaluation of the technical quality of software always includes a subjective element. Furthermore, even if the team were to agree on the perfect design, the attempt to reach this goal will inevitably decrease the marginal utility of the work performed. Thus design should only be improved as long as the work is cost-efficient.

In some cases, taking on design debt voluntarily may be warranted. For example, a new version of the software may be needed for an exhibition or product launch, or before the holiday season. In such cases it must be understood that if the software remains in use and requires changes or corrections, the interest on the design debt will become due at this stage. Basically, controlling design debt is about risk management and consciously considering the available options.

Timo Rantalaiho, Senior Software Designer

Timo Rantalaiho is an experienced software designer specializing in the development of challenging information systems and working with legacy code.