What technical debt actually means

The metaphor has been stretched until it covers everything anybody dislikes about a codebase. Recovering the original meaning is what turns it into something negotiable instead of a complaint.

The original claim

Ward Cunningham described shipping code that doesn't yet match your understanding of the domain, deliberately, to learn faster, and then paying the difference back once you understood better.

The debt is the gap between what the code says and what you now know. The interest is the extra effort every future change costs while that gap is open.

Both halves matter. Something with no ongoing cost isn't debt. It's code you'd write differently today, which describes most code.

What isn't debt

Code you find ugly that works and never changes. No interest is accruing, so rewriting it is a purchase, and repaying doesn't come into it.

A library you wouldn't choose today. It's debt only if it's costing you something now.

Anything that was never a trade. A bug is a bug. Calling it debt borrows credibility from a financial metaphor it hasn't earned, and that's why executives learn to discount the word.

flowchart TB
  D["is it debt?"] --> Q1{"was it a trade, deliberate or not?"}
  Q1 -->|no| B["a bug, or a preference"]
  Q1 -->|yes| Q2{"is it costing something now?"}
  Q2 -->|no| C["code you would write differently. not urgent"]
  Q2 -->|yes| E["debt. and the cost is the interest rate"]

Why the distinction is the whole negotiation

"We have technical debt" is unanswerable. It has no size, no rate and no consequence, so the reasonable response from anyone holding a budget is to wait until it has one.

"This costs us roughly a day a month and will cost more as the catalogue grows" is a proposal. It can be compared against other things a day a month could buy.

The reframing has real effects. A cost with a rate attached can be prioritized and a complaint can't, and most technical debt conversations fail at this step, well before any disagreement.

The interest rate is the number nobody computes

Some debt has a rate near zero. It sits there and costs nothing until you touch it, and you may never touch it.

Some compounds. The composite keys course established that changing a primary key gets more expensive with every row and every external system holding an identifier, and the strategy course generalized that into one-way doors.

Sorting your debt by rate instead of by irritation is the most useful thing this course asks for, and it usually reorders the list completely.

Key takeaways

• Debt is a gap between what the code says and what you now know, with interest attached.
• Without an ongoing cost there's no debt, only code you'd write differently.
• A bug called debt borrows credibility the metaphor hasn't earned.
• "We have technical debt" has no size or rate, so it can't be prioritized against anything.
• Sort by interest rate instead of irritation; it usually reorders the list completely.