Technical debt

Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future.

Common causes of technical debt include (a combination of):

• Business pressures, where the business considers getting something released sooner before all of the necessary changes are complete, builds up technical debt comprising those uncompleted changes
• Lack of process or understanding, where businesses are blind to the concept of technical debt, and make decisions without considering the implications
• Lack of building loosely coupled components, where functions are hard-coded; when business needs change, the software is inflexible.
• Lack of documentation, where code is created without necessary supporting documentation. That work to create the supporting documentation represents a debt that must be paid before the code can be considered maintainable by other developers.
• Parallel Development at the same time on two or more branches can cause the build up of technical debt because of the work that will eventually be required to merge the changes into a single source base. The more changes that are done in isolation, the more debt that is piled up.
• Delayed Refactoring. As the requirements for a project evolve, it may become clear that parts of the code have gotten unwieldy and must be refactored in order to support future requirements. The longer that refactoring is delayed, and the more code is written to use the current form, the more debt that piles up that must be paid at the time the refactoring is finally done.

"Interest payments" are both in the necessary local maintenance and the absence of maintenance by other users of the project. Ongoing development in the upstream project can increase the cost of "paying off the debt" in the future. One pays off the debt by simply completing the uncompleted work.

The build up of technical debt is a major cause for projects to miss deadlines. It is difficult to estimate exactly how much work is necessary to pay off the debt. For each change that is initiated, the project becomes committed to an uncertain amount of uncompleted work. The deadline is missed when the project realizes that there is more uncompleted work (debt) than there is time to complete it in. The Limited WIP Society is a professional association committed to the idea that to have predictable release schedules, a development team should limit the amount of Work In Progress in order to keep the amount of uncompleted work (debt) small at all times.

"As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it."

— Meir Manny Lehman, 1980

While Manny Lehman's Law already indicated that evolving programs continually add to their complexity and deteriorating structure unless work is done to maintain it, Ward Cunningham first drew the comparison between technical complexity and debt in a 1992 experience report:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

In his influential 2004 text, Refactoring to Patterns, Joshua Kerievsky presents a comparable argument concerning the costs associated with architectural negligence, which he describes as "design debt".

Activities that might be postponed include documentation, writing tests, attending to TODO comments and tackling compiler and static code analysis warnings. Other instances of technical debt include knowledge that isn't shared around the organization and code that is too confusing to be modified easily.

In open-source software, postponing sending local changes to the upstream project is a technical debt.

See also

• Big ball of mud
• Bit rot
• TODO, FIXME, XXX

External links

• Ward explains what debt metaphor is from YouTube (video) and C2.com (transcript)
• Steve McConnell discusses Technical Debt
• TechnicalDebt from MF Bliki
• Andy Lester's talk on "Getting out of technical debt"
• [1] Lehmans law
• Limited WIP Society website discusses techniques to avoid building up technical debt
• Managing Technical Debt Webinar by Steve McConnell