Stop Calling It Technical Debt !

In every project, someone says it sooner or later: "we have too much technical debt." Everyone agrees. Nobody asks how much.

One day I tried to do the math for real. I learned very little about my code, and a lot about the metaphor.

The bank statement

If my technical debt were a loan, it would have the same structure:

At the bank	In the code
The principal	The shortcut taken to ship on time
The interest	The extra cost of every new feature
Repayment	Refactoring
Bankruptcy	A full rewrite

So I listed my lines: a 3,000-line service with no tests, a framework three major versions behind, billing logic copied in four places, and one module everyone avoids.

Every feature costs me about 30% more time. And the principal, the amount I would need to pay to reach zero, is measured in months of work that nobody will ever give me.

The verdict: I am insolvent. And yet I ship every week, and I have been shipping for years. This is where the analogy breaks.

Four reasons why it is not a debt

I don't know the amount. A bank debt is a number written in a contract. Technical debt has no number, it has opinions. Ask three developers to rate the same module and you get three answers.

I never signed anything. You choose to take a loan. Most of my technical debt arrived on its own: a library abandoned by its author, a business rule that changed, a project I inherited. Ward Cunningham, who created the term in 1992, was talking about a loan you take on purpose, to learn faster. He then spent twenty years repeating that he never meant "badly written code."

The interest does not arrive every month. You only pay for the code you touch. I have terrible files that have not cost me a single minute in three years, because nobody goes there. And I have an 80-line file, changed twice a week, that is ruining me.

There is no zero balance. The refactoring I do today will be out of date in two years. I never repay anything. I just trade one debt for another one with a better rate.

The word itself is a problem

"Debt" suggests a mistake: someone spent badly. It makes teams feel guilty about decisions taken under pressure, and often taken by other people.

And a debt can be delayed. That is exactly what managers hear. The code, however, does not renegotiate anything.

What I say instead

• Talk about friction, not a balance. Not "this module is technical debt," but "any change to billing takes three weeks instead of three days."
• Talk about risk, not interest. An unpatched dependency costs nothing until the day it costs everything.
• Talk about what we can no longer do. The argument that works is not "we need to refactor." It is "the feature you want in Q3 is not possible with the current architecture."

In practice, I compare how often files change with how complex they are. What moves often and hurts, I fix. What sleeps, I let it sleep, even if it is ugly.

Conclusion

I will never repay my technical debt, because it is not a debt. It is the gap between a system written yesterday and a world that kept moving.

Let's keep the word for what it first meant: a shortcut taken on purpose, with open eyes. For everything else, let's stop doing imaginary accounting and simply look at where it hurts and what it stops us from building.

This is not bankruptcy. It is maintenance. And maintenance has no final payment.