Skip to content
Software Architecture Guide

Technical Debt

Explanation

Section titled “Explanation”

Technical debt is a metaphor. A team takes a shortcut, finishes sooner, and pays for it later. Fowler credits Ward Cunningham with introducing the metaphor in 1992.

Kruchten, Nord and Ozkaya define technical debt as design or implementation constructs that are expedient in the short term. “Expedient” means quick and convenient now.

Interest. In the metaphor, the extra effort needed to add new features is the interest paid on the debt. The more debt a system carries, the slower future change becomes.

Where debt lives. Debt is not only a code problem. SEI researchers hold that it is rooted in architecture and design issues. See Software Architecture for what architecture means.

Measuring it. Tools can measure some debt. The OMG Automated Technical Debt Measure standardizes a measure that source-code analysis tools can compute from quality characteristic measures. Architecture debt is hard to measure with tools.

Prudent or reckless. Fowler argues the useful question is not whether something is debt. It is whether the debt is prudent or reckless. Deliberate debt can be prudent when the team knowingly accepts it.

Repayment. In Cunningham’s view, a little debt speeds development, but only if the team pays it back promptly. SEI describes repayment through refactoring or rewriting. The Refactoring article explains refactoring.

Documenting it. arc42 section 11 holds the identified technical risks and technical debts, ordered by priority. Risk Storming is a related technique for finding risks.

Example

Section titled “Example”

A team must release a booking feature before a trade fair. It copies an existing payment module instead of building a shared one. The team writes this down as a known debt in the risks and debts section and plans to merge the two modules after the fair. Because the team chose this knowingly and recorded it, the debt is deliberate and tracked.

Trade-offs

Section titled “Trade-offs”

Deliberate debt buys speed now. The price is extra effort on every later change, and the benefit holds only if the team repays the debt promptly. Teams that accept debt knowingly (prudent) are in a different position from teams that take it recklessly. Architecture debt has deep roots but is hard to measure with tools, so tool numbers alone give an incomplete picture.

A shortcut gives speed now and creates interest that grows until the debt is repaid.

Diagram source 
flowchart LR
 A[Shortcut taken] --> B[Short-term speed]
 A --> C[Extra effort on later changes - interest]
 C --> D{Repaid promptly?}
 D -- yes --> E[Refactor or rewrite]
 D -- no --> F[Change keeps getting costlier]

Checks

Section titled “Checks”
  • Known technical debts are listed in the risks and technical debts section, ordered by priority.
  • Each deliberate debt is marked as knowingly accepted, with a plan to repay it (for example by refactoring).
  • Debt in architecture and design is covered, not only code-level debt.
Section titled “Related”

Sources

Section titled “Sources”