What Tech Debt Actually Is (and What It Isn't)
Tech debt is a tool for talking about trade-offs, not a synonym for code you dislike. Here's a more useful way to frame it.
"Tech debt" gets used to mean almost anything: a library someone doesn't like, a file that's too long, a decision made before they joined. That vagueness makes the term useless in planning conversations. Let's tighten it up.
A working definition
Tech debt is the gap between how your system is built and how it would need to be built to support what you're trying to do next.
The metaphor is financial on purpose. Debt isn't inherently bad — it's borrowed speed. You ship sooner by deferring work, and you pay interest in the form of slower future changes until you repay the principal.
What isn't tech debt
- Code you find ugly. Aesthetics aren't interest payments. If it's readable and changeable, style preferences aren't debt.
- Missing features. Not building something yet is a backlog item, not debt.
- Bugs. A bug is incorrect behaviour. Debt is correct behaviour that's expensive to change.
Lumping these together hides the one thing that makes debt actionable: it has a measurable cost on future work.
Deliberate vs. accidental
The useful split isn't "good debt vs. bad debt" — it's whether you took it on knowingly.
Deliberate debt is a loan you chose to take. Accidental debt is a loan you discovered you'd been paying interest on for a year.
Deliberate debt — "we'll hardcode this for the launch and revisit in Q3" — is fine, as long as it's written down. Accidental debt comes from not understanding the domain well enough at the time, and it's only visible in hindsight.
Making it visible
You can't prioritise what you can't see. The teams that handle debt well tend to:
- Name the interest, not the principal. "This costs us a day per feature in the checkout flow" beats "the checkout code is messy."
- Attach debt to the work it blocks. Debt with no upcoming work to slow down is, for now, free. Pay down the debt that's in your path.
- Budget for it continuously rather than waiting for a mythical "refactor sprint" that never gets scheduled.
Framed this way, tech debt stops being a complaint and becomes what it should be: a shared, honest way to talk about the trade-offs you're already making.