What is technical debt, explained without the metaphor doing the work

Technical debt is one of those terms that everybody in a meeting nods at and no two people mean the same thing by. For some it is any code they did not write. For others it is a polite word for a mess. Used that loosely it stops being a way to decide anything, which is a shame, because the original idea was specifically about deciding.

Where the term came from

Ward Cunningham coined it, in an experience report for the OOPSLA conference in 1992, describing a financial software system his team was extending. Martin Fowler, who has written the clearest short treatment of the idea, records that origin and defines the underlying condition as cruft: deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system further.

That definition is worth reading twice, because of what it leaves out. It says nothing about ugly code, old frameworks, or choices you would not have made. It is entirely about one thing: whether the next change is harder than it needs to be.

The interest is the only part that matters

The useful half of the metaphor is not the debt. It is the interest. Fowler puts it as a straight arithmetic: if a feature takes six days in the current codebase and would take four in a clean one, the two day difference is the interest you are paying, and paying off the principal is worth it only when you expect enough further features to earn the two days back.

This converts an aesthetic argument into a measurable one. A developer saying the code is bad is expressing a preference. A developer saying every change in the billing module takes three times as long as the equivalent change elsewhere is reporting an interest rate, and an interest rate can be compared against the cost of a rewrite.

It also explains the case people find counterintuitive: some genuinely bad code is correct to leave alone forever. If nobody ever modifies it, the interest rate is zero no matter how ugly it is. Debt in a module you touch weekly is expensive. The same debt in a module you have not opened in two years costs nothing.

Four kinds, and only two are worth arguing about

Fowler's other contribution is a two by two that stops the term being used as cover. Debt can be taken on deliberately or arrive inadvertently, and either can be prudent or reckless. He sets the four out with examples, and they behave very differently:

The reason to keep these separate is that they have different remedies. Deliberate prudent debt needs a date. Inadvertent prudent debt needs a refactor when you next pass through. Inadvertent reckless debt needs code review and a more experienced person, and no amount of rescheduling will touch it. Calling all four technical debt lets the third and fourth hide behind the respectability of the first.

How to tell tolerable debt from dangerous debt

Four questions, none of which require reading the code:

• How often do you change this part? Frequency is the interest rate. Everything else is secondary to it.
• Can one person estimate a change here confidently? If every estimate in one area comes with a shrug, that area is where the debt is, whatever the developers say about the rest.
• Does a change here break something unrelated? Coupling is the kind of debt that compounds, because the cost lands on work you did not think was involved.
• Would losing one particular person make this unmaintainable? Knowledge that exists only in a head is debt with a single point of failure attached.

Two yeses on frequency and coupling is the dangerous combination. Ugly, isolated, rarely touched code is the tolerable kind, and there is a lot of it in every system that has ever made money.

What to do about it, in order

Not a rewrite. Rewrites are how a debt conversation turns into an eighteen month project that delivers the same features later, and the reasons that happens are in why software projects fail, and why the average is the wrong number.

The sequence that works is duller. Find the two or three areas with the highest change frequency. Add tests there first, because you cannot safely improve code whose behaviour you cannot pin down. Then refactor in the course of work you were doing anyway, rather than as a separate initiative that competes with features and loses. Keep a written list of the deliberate debts with the reason and the date, so the prudent ones do not quietly become permanent.

Budget for it as a standing cost rather than a project. Software has a running bill after launch whether or not anyone plans for it, and the shape of that bill is set out in software maintenance cost after launch. Debt repayment lives inside that line, and treating it as an exceptional request is why it never gets approved.

The limit of the metaphor

Financial debt has a known principal, a stated rate and a schedule. Technical debt has none of those. You cannot look up the balance, the rate moves depending on what you happen to build next, and nobody sends a statement. That is why the metaphor is useful for explaining a tradeoff to a non technical audience and useless for planning against.

Fowler is direct about the failure mode: the metaphor gets used to justify neglecting internal quality, on the theory that the debt can always be paid later. In practice the interest is charged first, quietly, as slower delivery, and by the time anyone proposes paying down the principal the team has usually forgotten what the original decision was for. If a slipping delivery pace is the symptom you are actually seeing, the wider set of causes is in why software projects take so long, and what actually fixes it, and the cost side is in how to reduce software development cost, in the right order.

The one thing worth keeping from the metaphor is the question it forces. Not is this code good, but what is this costing us per change, and how many more changes are coming. Those two numbers decide it, and neither of them is a matter of taste.