Ward Cunningham was trying to explain something specific to his manager in 1992. He had written some code in Smalltalk that he knew wasn't quite right — it reflected his team's current understanding of the problem, not the fuller understanding they would eventually develop. Shipping it anyway was a calculated move, a way to get feedback fast. He reached for a financial metaphor: it was like borrowing money. You get the liquidity now, you pay interest later in the form of extra work, and eventually you settle the principal by refactoring the code to match your improved understanding. Clean, bounded, almost elegant.
Thirty years later, I sat in a planning meeting where an engineering manager used the phrase "technical debt" to describe a logging library that nobody liked the API of, a test suite that ran in eleven minutes instead of four, a set of microservices that had been named inconsistently, and a database schema that was genuinely causing production incidents. He treated all four as entries in the same ledger. The room nodded along. I kept quiet, but I left thinking: Cunningham's metaphor has been so thoroughly misunderstood that it now does more harm than good.
That is the thing about a good metaphor. It illuminates until it obscures.
What Cunningham Actually Said — and Didn't
The original formulation was narrow in a way that almost nobody remembers. Cunningham wasn't talking about messy code written by careless engineers. He wasn't talking about legacy systems, or outdated dependencies, or rushed sprints, or any of the dozens of things the phrase now carries. He was talking about the gap between what the code embodies and what the team now knows. The debt was epistemological, not aesthetic. You shipped code that encoded an earlier, incomplete model of the domain. As your understanding matured, the code fell behind. That lag was the debt.
Cunningham himself grew uncomfortable watching the metaphor expand. In a 2009 video interview, he said plainly that the debt analogy was being misapplied — that people were using it to excuse writing bad code on purpose, which was never the point. Bad code isn't debt. Bad code is just bad code. Debt, in his framing, was a byproduct of learning, not of laziness or schedule pressure.
But by 2009 the phrase had already escaped. It was too useful as a rhetorical device — a way for engineers to talk to business people using a vocabulary business people understood. Interest. Principal. Repayment. The finance frame made technical decisions legible to non-technical stakeholders, and that was genuinely valuable. The trouble is that legibility came at a cost: precision.
When the Metaphor Became a Trash Category
Once a metaphor becomes a management term, it tends to absorb everything adjacent to it. Technical debt became the bucket into which engineers poured every source of friction they couldn't immediately fix. Slow builds. Inconsistent naming. Missing documentation. Architectural decisions that made sense in 2017 and don't anymore. Actual bugs that had been open for two years. All of it became "debt."
This matters because the financial metaphor carries implicit assumptions that don't apply equally to all these things. Debt implies a creditor — someone you owe. It implies a principal that can, in theory, be repaid in full. It implies that interest accrues predictably, that you can model the cost of waiting. None of that maps cleanly onto, say, a sprawling service that was designed for a scale you no longer operate at. You can't "repay" it the way you repay a loan. You might rewrite it, or decompose it, or simply route around it for years. The payoff function is nothing like amortization.
Worse, the debt framing quietly assigns moral weight. Debt is something you owe. It implies obligation, even guilt. I've watched teams spend months "paying down technical debt" on systems that were working fine, because the phrase had made the status quo feel irresponsible. The metaphor had become a source of anxiety rather than a planning tool.
The most honest thing I can say is this: when a word means everything, it means nothing. And right now, technical debt means everything.
The Damage Done in Meetings
The practical consequence of this conceptual sprawl is that conversations about technical debt are almost always unproductive. I don't mean that as a cynical aside — I mean it structurally. When you walk into a meeting with a list of "technical debt items" that includes an unloved API, a slow test suite, a naming inconsistency, and a schema that is actively causing incidents, you have already lost the conversation before it starts. You've collapsed four different problems — with four different causes, four different costs, four different remediation strategies — into a single category, and now you're asking stakeholders to reason about them collectively.
The incident-causing schema is an emergency. The slow test suite is a productivity tax. The naming inconsistency is a cognitive friction that compounds over time but has no acute cost. The unloved API is a matter of taste that may never need to change. These are not the same kind of problem. Treating them as entries in a shared ledger doesn't clarify the decision — it muddies it.
Engineers often defend the umbrella term because it gives them a way to surface concerns to non-technical leadership. And I understand that instinct. But I'd argue the metaphor has become a crutch that lets us avoid the harder work of actually characterizing what's wrong and why it matters. "We have technical debt" is a way of saying something without saying anything. It's the engineering equivalent of telling your doctor you feel bad.
Toward More Honest Language
I'm not suggesting we retire the phrase entirely — it has genuine communicative value when used with care, in the specific sense Cunningham intended. When a team ships a feature knowing that the implementation reflects their current understanding and will need revisiting as that understanding deepens, calling that a debt is accurate and useful. It sets an expectation. It schedules a conversation.
But for everything else, we might do better with more honest, more specific language. An architectural decision that made sense then and doesn't now isn't debt — it's obsolescence. A system that was never designed well isn't debt — it's damage. A dependency that hasn't been updated in four years isn't debt — it's risk. These words carry different implications, point toward different remedies, and don't come pre-loaded with the guilt and urgency that "debt" smuggles in.
Some teams I've talked to have started categorizing their backlogs differently: there's work that's urgent because something is actively breaking, work that's important because it's compounding cost over time, and work that's desirable because it would make the codebase more pleasant to work in. None of those categories need the debt metaphor to be legible. They just need honest assessment.
The technical debt metaphor misunderstood isn't a minor semantic complaint. It shapes how teams allocate time, how engineers communicate with leadership, how organizations decide what to fix and what to tolerate. A blunt instrument used in place of a precise one doesn't just fail to cut cleanly — it bruises.
Cunningham gave us a scalpel. Somewhere along the way, we turned it into a catchall drawer where we throw everything we don't want to deal with right now. The question worth sitting with isn't how to pay down your technical debt — it's whether you actually know what you're carrying, or whether you've just given your discomfort a name and called it a plan.