>Ward Cunningham, one of the authors of the Agile Manifesto, once said that some problems with code are like financial debt. It's OK to borrow against the future, as long as you pay it off.
-- [What is techinical debt](https://www.agilealliance.org/wp-content/uploads/2016/05/IntroductiontotheTechnicalDebtConcept-V-02.pdf)
The problem with the idea of Technical Debt is not that it is not accurate (though it isn't), it's that "business people" *like debt*. As a naive engineer, I thought that telling managers that we would be introducing technical debt would have them be wary, use it infrequently, and keen to pay it down. On the contrary, I now realize that subsequent events are explained by the fact that managers *love* debt. "I can get something for free now and pay for it later? Cool! More of that please!"
So if you are an engineer, do yourself a favor and stop using the term. So what are people talking about when they say "technical debt"?
There's two things, usually. One is failure to manage scope, and the other is failure to maintain a clean workshop.
### Failure to manage scope
Debt would be if someone said "I need to build a bridge across here that can handle an Army, and I've got $1m", we engineers reply "It will take $2m", and they respond "Ok, I will borrow $1m so you can build the bridge I need". You are now $1m in debt.
Instead what happens is they say "Well, build what you can for $1m", and you say "Ok, we can make 'a bridge' for that", and then either (a) your infantry can cross, but the tanks have to get diverted 20 miles out of the way, or (b) the tanks end up in the river along with the bridge. Since (b) is bad, you then have to spend a lot of time planning the routes for the tanks, and making sure the tanks have the right air cover, etc etc, i.e. doing more work.
More likely, however, is that the manager, who is not a structural engineer, sees a perfectly good bridge and orders the tanks across anyway, causing the loss of the bridge, the tanks, and the war.
It's not debt. It's just (at best) an incomplete solution or (at worst) a bad solution that fails at the worst possible moment - e.g. database collapses during registration for the largest event of the year.
Ah, but surely, if you build the lightweight solution for $1m, and acknowledge the increased costs of managing the problems that it doesn't solve, then thats fine? Maybe the tanks won't show up immediately? Sure, but that's not technical debt either! That is scoping: we (engineers + business) identify a workable solution that provides some business value. And then we do that well. When Cunningham, for example, talks about what to do about debt, e.g. YAGNI, these are all good ideas: scoping. But the term "debt" is incorrect in this case. The term "debt" will only ever get a team in trouble as it indicates that the team is unwilling to confront the actual problem as engineering, but only as a broken metaphor.
### Failure to maintain a clean workshop
Good craftspersons keep their tools clean and oiled. It is not simply that a new tool can cost money, it is that when a job needs a tool, and that tool is not working, you can lose the job, and that's far more than the cost of the tool. In 2024, [CBS reported](https://www.cbsnews.com/news/bugs-mold-mildew-inspection-boars-head-plant-listeria/) "Bugs, mold and mildew found in plant linked to deadly listeria outbreak". Why waste money cleaning your factory? Oh, nine dead, that's why.
There's a lot to write on this, so I'll leave this for now.