What is the "technical debt" metaphor introduced by Ward Cunningham, and what do "principal" and "interest" mean in it?
answer
- Cunningham 1992, learning not sloppiness
- Principal = one-time fix cost
- Interest = recurring tax per change
- Interest compounds via imitation
- End state: technical bankruptcy
basics
~20 sIt compares design shortcuts to borrowing money. The principal is the one-time effort to fix the shortcut properly; the interest is the extra effort every future change costs while the shortcut remains. Shipping fast borrows; refactoring repays.
solid answer
~50 sWard Cunningham coined the metaphor in 1992 to explain to non-technical stakeholders why teams spend time restructuring working software. Shipping code whose structure does not match your best current understanding of the domain is like taking a loan: you get value now (earlier release, earlier feedback) but you owe something. The principal is the one-time cost of realigning the design - the refactoring itself. The interest is the recurring tax paid meanwhile: features take longer, changes are riskier, defect rates and onboarding time rise. Interest compounds, because new code layered on a poor structure copies and amplifies it. The managerial point: debt is not automatically bad - like financial debt it can be a rational investment - but unserviced debt eventually consumes delivery capacity, which is when velocity visibly collapses and a team appears to "stop delivering".
go deeper
Define the metaphor, name principal and interest, and give one concrete example such as duplicated logic in several places.
Add that interest compounds through imitation, that debt can be a rational trade-off, and that repayment priority depends on interest rate rather than ugliness.
Frame it as an economic decision: estimate interest from churn and change cost, prioritize by interest rate, and explain the trade-off in delivery terms.
Discuss portfolio-level debt management, the risk of technical bankruptcy, when to deliberately leave debt unpaid, and the limits of the financial metaphor itself.
## Origin Ward Cunningham (inventor of the wiki, co-author of the Agile Manifesto) described the idea in a 1992 OOPSLA experience report about financial software. His framing was about **learning**, not sloppiness: while building software you also learn the domain. You ship a version reflecting your *current* understanding; as you learn more, the code no longer matches your *best* understanding. That gap is the debt, and refactoring repays it by folding new understanding back into the design. ## The two quantities - **Principal** - the one-time effort to restructure the code so it matches what you now know. Example: extracting a pricing rule that was copy-pasted into four screens into one module. Measured in engineer-days. - **Interest** - the *recurring* extra cost paid while the debt is outstanding. Every new price rule must be changed in four places, every change risks missing one, QA retests four screens, new joiners must learn all four. Measured as slower delivery, higher defect rate, more coordination. Interest is what actually hurts. Debt with a high principal but near-zero interest (an ugly module nobody touches) can be left alone indefinitely; debt with a small principal but high interest (confusing structure in the most frequently changed component) should be paid immediately. This asymmetry is why "amount of ugly code" is a poor metric and "cost of change where we actually change things" is a good one. ## Why interest compounds New code imitates the code around it - developers copy the existing pattern because it looks like the house style and because imitation is the shortest safe path through unfamiliar code. So one bad decision seeds ten, and the principal itself grows. This is the mechanism behind the "rewrite trap": a team waits so long that repayment appears larger than the value of the system. ## Bankruptcy The end state of unserviced debt is *technical bankruptcy*: nearly all capacity goes to servicing interest (bug fixing, workarounds, manual regression) and none to new value. Recovery options then are limited and expensive - freeze and pay down, strangle the system with a replacement, or rewrite. ## Where the metaphor helps Its real value is communication with people who control budgets. "We need to refactor" is a cost with no visible benefit; "we pay roughly two extra days on every change in checkout, and five days of work removes that" is an investment decision a manager can evaluate.
- If interest is what hurts, how do you estimate it for a specific piece of debt?Proxy it with change frequency times friction: how often the area is modified (version-control churn), how long recent changes there took versus comparable areas, defect density and rework in that module, and the questions it generates during onboarding. High churn plus high complexity means high interest.
- Is taking on technical debt ever the right call?Yes - to hit a market window, to validate a hypothesis before investing in a proper design, or when the code has a short expected life. The condition is that the decision is conscious, recorded, and has a repayment trigger; otherwise it is not a loan, just damage.
- Why is 'we will refactor later' usually not enough?Because there is no trigger, no owner and no budget. Undated intentions lose to dated feature commitments every sprint, while interest compounds. Debt needs to be tracked as work with a condition that forces it into a plan.
A credit card for engineering time. Buying the feature now on credit is fine if you can service the payments; ignore the statement long enough and the minimum payment consumes your whole income.
saying these in an interview costs you the question
- Calling every piece of bad or legacy code 'technical debt' - the metaphor is about a gap between design and current understanding, not about incompetence alone
- Saying debt must always be repaid immediately; some debt is cheaper to carry than to fix
- Confusing principal and interest, or estimating only the fix cost and never the ongoing cost
- Claiming debt is only created by managers pushing deadlines - much of it comes from learning and drift
- Using 'technical debt' as a blanket excuse to ship knowingly broken code