Technical Debt Is About Interest, Not Ugly Code

Almost every engineering team keeps a technical debt list. Almost none of them are looking at technical debt. What they have is a list of code somebody dislikes, which is a completely different object, and the confusion between the two is the reason the refactoring budget never gets approved.

The term has a precise origin, and the origin turns out to be far more useful than anything the industry built on top of it. Ward Cunningham coined it in 1992, in a short experience report at OOPSLA about the WyCash Portfolio Management System, a bond portfolio tool his team was building in Smalltalk.^[1] He was not writing a manifesto. He was explaining to a room of object-oriented programmers why his team kept rewriting parts of a shipping product and why that was a feature rather than an embarrassment.

What Cunningham actually wrote

Here is the whole thing, from the 1992 report:

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”^[1]

Read it for what it does not say. It does not say write sloppy code. It does not say skip tests. It does not say cut corners under deadline pressure. The debt is shipping first time code, code written before you fully understand the problem, in order to get the product in front of reality sooner and learn what the problem actually is. The interest is the time you lose working against a structure that encodes an understanding you have since outgrown.

Cunningham got asked about this often enough that in 2009 he recorded a short video to correct the drift. His words there are blunt. If you want to go into debt by developing software you do not completely understand, he says, “you're wise to make that software reflect your understanding as best you can.”^[2] And the failure mode he describes is not messiness at all:

“If you develop a program for a long period of time by only adding features but never reorganizing it to reflect your understanding of those features, then eventually that program simply does not contain any understanding and all efforts to work on it take longer and longer.”^[2,3]

The interest test

Here is the part that makes the metaphor operationally useful, and it is the part that gets skipped. Debt is only debt if it charges interest. Not metaphorically. Structurally. A loan with a zero percent rate that nobody ever calls in is not a financial problem, and code that is ugly but never touched again is not an engineering one.

So the test is one question: does it make the next change to this area slower? If yes, you can measure the interest, price it, and argue about whether refinancing is worth it. If no, you have found something you dislike, which is fine, but disliking code is not a business case.

Fowler's quadrant, and why it matters for the conversation

On October 14, 2009, Martin Fowler published the technical debt quadrant, which sorts debt on two axes: was it deliberate or inadvertent, and was it prudent or reckless.^[4] The four cells are worth naming, because each one implies a different fix.

• Deliberate and prudent: “We must ship now and deal with the consequences.” This is Cunningham's debt, and it is the only kind you would ever choose on purpose.
• Deliberate and reckless: “We don't have time for design.” A decision, but a bad one. The fix is a process fix, not a code fix.
• Inadvertent and reckless: “What's layering?” Nobody decided anything. The fix is hiring, training, or review, and refactoring alone will regenerate the same problem in six months.
• Inadvertent and prudent: “Now we know how we should have done it.” Fowler calls this inevitable even for excellent teams, and he is right. You cannot prevent it. You can only budget for it.

The quadrant earns its place because it kills the moralizing. Two of the four cells involve no bad judgment at all, and one of them is unavoidable by construction. When a team lumps all four into one list titled “tech debt” and takes it to a planning meeting, the implicit message an executive hears is “we made mistakes and now we want time to fix them.” That framing loses every time it competes with a revenue feature.

“We'll fix it later” is not a plan

Cunningham's formulation has a repayment clause built in: a little debt speeds development so long as it is paid back promptly with a rewrite.^[1] Drop that clause and the metaphor stops describing debt and starts describing a default.

A real intention to pay has three parts: a trigger condition, an owner, and a stated interest rate. Without a trigger, “later” is never, because there is no moment at which anyone is obliged to act. I have had good luck writing this straight into the code, next to the thing it describes, where it is impossible to lose:

// DEBT (deliberate, prudent): the export path assumes one tenant per account.
// Why: we shipped this before the enterprise plan existed and had one customer.
// Interest: every new report type needs a hand-written tenant filter, ~1 day each,
//   plus one production incident so far (INC-412) from a filter that was forgotten.
// Trigger: the second enterprise tenant signs, or 2026-12-01, whichever comes first.
// Owner: payments team. Estimated payoff: 5 days.
export function buildExport(accountId: string) {
  // ...
}

Four lines of comment, and the item now has everything a planning conversation needs. Note that the interest line is the load-bearing one. “One day per report type plus one incident” is a number somebody can multiply by the number of report types on next quarter's roadmap. “This is hacky” is not.

The same discipline applies to the debt that has its own dedicated ledger. A flag left on after its rollout finished is textbook deliberate debt with no trigger attached, which is exactly the argument in why a feature flag is a production change that skips your deploy pipeline. And the largest version of this decision, whether to pay down architectural debt by splitting a system apart, deserves its own analysis rather than a reflex, which is what deciding between a monolith and microservices works through.

Making the interest visible to people who hold the budget

Engineers describe debt in nouns: the module, the schema, the framework. Budget holders buy verbs and numbers: this is slower, by this much, costing this. The translation layer is delivery metrics, scoped to the affected area rather than the whole codebase.

Two of the four DORA keys do most of the work here. Change lead time is defined as the amount of time it takes for a change to go from committed to version control to deployed in production.^[5] Change fail rate is the ratio of deployments that require immediate intervention following a deployment.^[5] Both are directly sensitive to the thing you are claiming: if a subsystem really is charging interest, work that touches it takes longer to get out and breaks more often when it does.

Three artifacts, in order of how convincing they are:

1. Change lead time, filtered to the affected paths, against the repository baseline. If pull requests touching that directory take three times as long to reach production as everything else, you are not describing taste, you are describing a measured slowdown.
2. Change fail rate for deployments touching that area. A subsystem that produces a disproportionate share of the rollbacks and hotfixes has a defect cost attached to it, and defect cost is a language finance already speaks.
3. Two or three named tickets that ran three times over estimate, with the specific reason. Not a chart. A story with an identifier on it. Charts get argued with; “this took nine days and here is the commit where we found out why” does not.

One caution before you go build a dashboard out of this. Metrics borrowed to win an argument have a habit of becoming targets, and a lead time number that the team is now judged on will improve without anything underneath it improving. That failure mode has its own catalog, in the ways engineering metrics get gamed. Use these numbers to size one decision, then put them down.

The honest case for never paying some of it back

Here is where I part company with most writing on this subject. A lot of technical debt should be carried to the grave, deliberately, and saying so out loud is what makes the rest of your argument credible.

The math is not complicated. Paying down debt costs principal, which is engineering time you could have spent on something else. It returns avoided interest, which is future time saved on future changes. If the area is stable, if the roadmap does not point at it, if the service is being decommissioned in eighteen months, then the avoided interest is near zero and the principal is real. Paying it is a straight loss dressed up as professionalism.

The same logic scales up. A modernization program that touches everything, rather than the two systems the roadmap actually runs through, is a very expensive way to pay off loans nobody was calling in, which is why sequencing a platform modernization is mostly an exercise in deciding what to leave alone.

What I would actually do on Monday

Take your technical debt list and run every item through the interest test. Anything that fails it moves to a separate document, call it “code we would write differently,” and stop bringing it to planning. Anything that passes gets three additional fields: what it costs per change, what triggers the payoff, and who owns it. Whatever survives that filter is short, specific, and priced, and a short specific priced list is a thing an executive can say yes to.

The reason this works is not that it is a clever framing. It is that it is the original meaning. Cunningham gave the industry a financial metaphor with a repayment clause and an interest rate in it, and the industry kept the word and threw away both of the things that made it operate. Thirty-four years on, the fix is not a new framework. It is reading the 1992 paragraph again and asking, of each item on the list, what exactly you borrowed and what exactly you are paying.