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 prob