Technical debt is a decision someone made, not an accident

In a meeting, a product manager said the team had “let a lot of technical debt build up”. Nobody objected. Yet every shortcut in that code had been approved, weighed, sometimes imposed, in meetings whose minutes I still had. The word “let” alone did all the political work in that sentence.

The original image was about a deliberate loan

Ward Cunningham, who introduced the metaphor, described something precise: shipping fast with an imperfect understanding of the problem, accepting to pay interest in the form of slower work later, on condition of paying the principal back once you understand better. It’s a financing choice, not negligence.

Martin Fowler later sorted these situations along two axes: debt can be deliberate or inadvertent, prudent or reckless. Those categories are useful because they make visible what everyday usage erases. Poor code written out of ignorance and code simplified to hit a release date are two different things, with two different owners.

In corporate usage, all of that flattened into one meaning: technical debt means dirty code, dirty code comes from developers, and developers should be more rigorous. The financial metaphor lost exactly the part that talked about the lender.

Following who decides and who pays

Take an ordinary trajectory. A date is set before the scope is known, because it has been announced to a client or a board. The team reports that the proper feature needs six weeks and the quick version needs two. They take the quick version, with a promise to come back to it. The demo goes well, the quarterly target is hit, and so is the bonus.

Nobody comes back to it. Six months later, every change costs three times as much, the patches multiply, and people start talking about code quality. The people who benefited from the short-term gain are no longer the ones paying the interest, and sometimes they’ve left the company altogether.

The same mechanism works at hiring time. A team cut back to hold a product budget mechanically takes more shortcuts, and that reduction never shows up in the code quality report. We measure the team’s velocity, never the constraint we placed on it.

This gap isn’t unusual. It’s the normal structure of the incentive system. A quarterly target gets measured and rewarded. Maintainability eighteen months out appears on no dashboard until it has already cost a lot. As long as the shortcut pays off for the person deciding, it will be decided, and lamenting it in a retrospective won’t change anything.

I say this without looking down on anyone: I’ve shipped things I knew were fragile, and I’ve let deadlines slip rather than open the conflict. It’s comfortable to treat those episodes as technical accidents.

What changes when you name the decision

The only thing that has worked, in my experience, is forcing the trade-off to be written down. Not a vague ticket called “refactor the module”, but a line in the decision itself: we choose the quick version, it saves us this much time, it will cost us this much work later, and here is the date when we decide whether to pay it back or live with it.

The effect isn’t magic, the debt still exists. But it stops being a floating moral failing attributed to the team. It becomes what it really is: a loan taken out by an organisation, with an identifiable beneficiary and a due date.

Since then, whenever I hear “we have a lot of technical debt”, I ask who borrowed it. The meeting gets shorter.