Technical Debt Is Not a Bank Account

The metaphor is thirty years old and it has earned its place: it gave engineers a way to explain a real cost to people who control budgets, in a language they already spoke. That was worth a great deal.

It has also quietly installed three assumptions that are wrong, and teams plan around them anyway.

Assumption one: the balance is knowable

Debt implies a figure. Someone could, in principle, tell you what you owe. But most of what slows a codebase down is not on any list. It is not the TODO comments or the ticket backlog, which are the parts that got written down precisely because someone understood them. It is the coupling nobody has noticed yet, and it becomes visible only when a change runs into it.

Which means the balance is not merely unknown, it is not defined until you attempt the work. Teams that build a debt register are cataloguing the part they can already see, and that part is rarely what hurts.

Assumption two: repayment is fungible

Money is interchangeable, so a debt metaphor suggests any amount of remediation helps proportionally. It does not. Coupling is a graph, and cutting the wrong edge changes nothing at all.

This is the mechanism behind the refactoring quarter that produces no measurable improvement. The work was real and the code did get better, but none of it was on the path of the changes the team actually needed to make. The interest kept accruing at the same rate.

Assumption three: interest is the problem

The framing says you pay a little extra on every change forever. In practice the cost is not a steady tax, it is a cliff. Ninety percent of changes are unaffected and the tenth is impossible, and you cannot tell which is which until you are in it.

That is why estimates fail so asymmetrically. A team is accurate for months and then one ticket takes eleven days, and the retrospective concludes that estimation needs work. Estimation was fine. The distribution has a tail, and averages do not describe tails.

A better frame

Treat it as terrain rather than debt. Some parts of the system are easy to move through and some are swamp, you find out by walking, and the useful question is not how much you owe but which direction you are heading.

Practically, that means: do the remediation immediately ahead of the feature that needs it, rather than in a dedicated quarter. Let the roadmap select what gets cleaned, because the roadmap knows which edges are on the path and a debt register does not.

And stop promising a number to people who will hold you to it. You do not have one. Saying so plainly buys more credibility than a spreadsheet that turns out to have been fiction.