Technical Debt: The Loan Nobody Remembers Taking
When Ward Cunningham coined the term in 1992, he was not describing bad code. He was trying to explain to non-technical managers why a team that had shipped successfully was now asking for time to go back and restructure something that already worked.
His analogy was financial. Shipping a first version quickly, with an imperfect understanding of the problem, is like borrowing money: you get something valuable now, sooner than you otherwise could, and you commit to paying interest later. The interest is paid in the form of every future change being slightly harder than it needed to be.
The metaphor caught on so thoroughly that it has been partly corrupted. "Technical debt" is now used as a synonym for "code I don't like" or "the mess my predecessors left." That usage loses the two things that made the original insight valuable: debt can be a rational choice, and debt has an interest rate that compounds.
The mechanism: interest paid in future changes
The reason the financial analogy holds so precisely is that the cost structure is genuinely the same shape.
A shortcut saves time once, at the moment it is taken. Its cost is not a single future payment — it is a small tax on every subsequent interaction with that part of the system. Every new feature that touches it takes longer. Every bug in the vicinity is harder to diagnose. Every new engineer spends longer understanding it. Every test around it is more fragile.
That structure — a small recurring cost levied on a growing base of activity — is exactly compound interest, and it produces the same characteristic curve. For a long time the effect is genuinely negligible, which is why early warnings sound like perfectionism. Then the curve bends. Teams typically experience this as a sudden, inexplicable collapse in delivery speed, and go looking for a recent cause: a bad hire, a process change, a difficult quarter. The actual cause is years of accumulated interest arriving on a base that finally grew large enough for it to matter.
There is a second-order effect that makes it worse. High debt makes further shortcuts more attractive, because doing things properly in a tangled system is genuinely more expensive than doing things properly in a clean one. The debt therefore has a reinforcing feedback loop attached: past shortcuts raise the price of rigour, which produces more shortcuts.
Four kinds, and only one is negligence
Martin Fowler's extension of the metaphor is the most practically useful refinement, because it separates cases that require completely different responses. Two axes: was the shortcut deliberate or inadvertent, and was it prudent or reckless?
Deliberate and prudent — "We know the right design; we are shipping the simpler one to hit this window, and we will revisit it." This is the original meaning and it is frequently the correct decision. A team that never does this is over-engineering and will lose to a faster competitor.
Deliberate and reckless — "We don't have time for design." The shortcut is chosen knowingly, but without understanding what is being traded away. This is where most genuinely destructive debt originates.
Inadvertent and prudent — "Now that it's built, we finally understand how it should have been structured." This is unavoidable and not a failure at all. You frequently cannot know the right architecture until you have built the wrong one, which is the practical content of Gall's Law.
Inadvertent and reckless — the team did not know a better approach existed. This is a capability problem, not a scheduling one, and no amount of refactoring time fixes it.
The value of the taxonomy is that it stops the argument about whether debt is acceptable — obviously some is — and moves it to the question that actually matters: which kind is this, and did we choose it?
Managing it in practice
Name it out loud, in writing. The single largest difference between organisations that manage debt and those that drown in it is whether the debt is recorded. Undocumented shortcuts are indistinguishable from intentional design to everyone who arrives later. Six months on, nobody can tell which oddities were deliberate compromises and which were considered decisions — so nobody dares change either.
Attach it to the work, not to a separate backlog. "Technical debt tickets" in a parallel list are systematically deprioritised against features, because they compete for the same attention while lacking a customer asking for them. Debt gets repaid most reliably when it is repaid as part of the next change to that area — you touch it anyway, so you leave it better.
Track the interest, not the principal. The relevant question is not "how much bad code exists" but "what is it costing us per month." Debt in a stable, rarely modified corner of the system may be genuinely fine to leave forever; the interest rate is near zero because nobody touches it. Debt in the most frequently changed module is expensive at a fraction of the volume. This is a direct application of the Theory of Constraints: repay debt at the bottleneck, not wherever it is most visually offensive.
Resist the total-rewrite instinct. Rewrites are the debt equivalent of a consolidation loan taken at a worse rate: they consume enormous capacity, they lose undocumented behaviour that accumulated for good reasons, and — per Conway's Law — if the organisation that produced the original structure is unchanged, the rewrite will drift back toward the same shape.
Accept that zero debt is the wrong target. An organisation with no technical debt has almost certainly been shipping too slowly. The goal is a debt load that is deliberate, visible, and serviced — which is exactly how a healthy business treats financial leverage.
Cunningham's point was never that borrowing is bad. It was that borrowing without knowing you have borrowed is how organisations end up making interest payments they never agreed to, on a principal nobody remembers taking on.
