A finance director once told us his development team had been "talking about technical debt for a year" and he had no idea whether it was real or a way of avoiding deadlines. That is a fair suspicion, and it exists because the metaphor explains nothing to the person holding the budget.

Here is the version without the metaphor.

What it actually is

Technical debt is work that was deferred, and which now makes every subsequent change slower.

That is the whole concept. A shortcut taken in month three means a feature in month twenty takes six days instead of two. The difference — four days, every time, forever — is the interest.

It is not bad code. Bad code is bad code. Debt is a deliberate trade made for good reasons that has not been revisited.

Where it comes from

  • Deadline pressure. The most common and often the most defensible. Shipping in time for a season is worth some future slowness.
  • Changed requirements. The system was designed for one shape of business and the business changed shape. Nobody was careless; the ground moved.
  • Learning. The team knows more now than it did. The old approach was reasonable with the knowledge available.
  • Departures. The person who understood a module left. The code did not change, but the cost of touching it did.

Notice that only the first is a choice. The rest accumulate no matter how disciplined the team is, which is why debt is a permanent condition rather than a failure state.

How to price it

Do not ask the team how much debt there is. Ask three measurable questions.

How long does a small change take now, compared to a year ago?

If a two-day feature has become a five-day feature and nothing about the feature grew, the difference is interest. Multiply by how many changes you make a year and you have an annual cost in days.

How often does a change break something unrelated?

Track it for two months. A high rate means the system's parts are entangled — which is expensive in testing time and, eventually, in customer trust.

How many people can safely change each area?

If the answer for any critical module is one, that is not technical debt, it is a business risk with a name and a notice period.

Which debt to repay

Not all of it. Paying down debt in code nobody touches is spending money to tidy a room you never enter.

Repay debt where change is frequent. The test we use: overlay the list of problem areas onto the roadmap for the next two quarters. Anything that appears on both lists is worth fixing. Everything else can wait, possibly forever.

Why the rewrite is usually the wrong answer

When debt becomes painful, someone proposes rebuilding from scratch. It is almost always a mistake, for a reason that is easy to miss.

The existing system contains years of accumulated corrections — the odd tax case, the client who needs a different invoice format, the fix for the bug nobody documented. Those are invisible in the code and absent from any specification. A rewrite discards them, and you rediscover each one in production.

Incremental replacement is slower to feel satisfying and far more likely to work: strangle one module at a time, keeping the old system running until each piece is genuinely replaced.

How to talk about it with a board

Stop saying "technical debt". Say the number.

"Changes to the ordering system take three times longer than changes elsewhere. We make about forty such changes a year. That is roughly eighty developer-days annually. Fixing the underlying issue costs thirty days once."

That is a proposition anyone can evaluate. The metaphor is not.

What healthy looks like

Not zero debt — that costs more than it saves. Healthy is knowing where the debt is, having decided deliberately which parts to carry, and reviewing that decision when the roadmap changes.

The teams in trouble are not the ones with debt. They are the ones who cannot tell you where it is.