Technical debt as a metaphor and as a decision

What it is

Ward Cunningham's metaphor, as summarised by Fowler, compares a quick-and-dirty design choice to taking on debt: it lets you deliver sooner, but you pay interest in the form of extra effort on every later change until the principal is repaid by cleaning up. Fowler distinguishes deliberate from inadvertent and prudent from reckless debt.

Why it matters

The metaphor gives non-technical stakeholders a way to reason about maintenance work. It is only useful when the debt is visible: a known shortcut, a note in the code, a ticket, a record of why it was taken.

How to apply

• When taking a deliberate shortcut, record it (issue, ADR, or a TODO with an identifier) with the cost you expect to pay.
• Review the register regularly and repay the debt that is charging the most interest: the parts that change most often.
• Do not label every disliked design as debt; a design that never needs changing costs nothing.
• Reserve capacity for repayment in planning rather than hoping for a quiet period.

Pitfalls

"We will clean it up later" without a record is not debt, it is a hope. Rewrites justified as "paying off all debt" often recreate the debt in a new place. Interest is paid in time and defects, so the measure of debt is friction on change, not code aesthetics.