The technical debt you can see is rarely the expensive kind.

A metaphor read backwards

Ward Cunningham, who introduced the debt comparison, was not talking about sloppy work. He described something specific: you ship a first version reflecting the understanding of the domain you had at the time, knowing that understanding will change. The interest on the debt is the time spent working with software that still encodes the earlier understanding.

The distinction is not academic. In the popular reading, debt is a quality failure a developer could have avoided by being more careful. In the original reading, it is the normal consequence of shipping early and learning afterwards. The first invites blame. The second invites repayment.

Martin Fowler offered a useful grid for telling cases apart, crossing two axes: was the debt deliberate or inadvertent, and was the reasoning prudent or reckless? A shortcut taken knowingly to hit a date is deliberate and prudent. Ignoring conventions out of carelessness is reckless. And the most interesting category is neither of those.

The debt no tool detects

Inadvertent, prudent debt is what appears when a capable team, after eighteen months of serious work, finally understands how the domain should have been modelled. Nobody did a bad job. The software is simply built on a definition of the business that no longer holds.

It does not show up in a static analysis report. It shows up differently: an innocuous request touches eleven places, a rule means different things depending on which module applies it, nobody can say where a business concept is actually defined. Those symptoms — not the warning count from a quality tool — predict what the next six months will cost.

The cost of debt is not measured by its volume, but by how often you have to walk through the area that carries it.

Why a standalone debt budget gets cut

The usual organizational response is to ask for an envelope: a refactoring quarter, a reserved share of capacity, a modernization programme. Those requests often fail, and not for lack of goodwill.

They fail because they cannot be verified from outside. An executive approving a technical debt envelope is buying a promise of improvement with no observable delivery, competing against initiatives that promise a dated outcome. At the first difficult trade-off, that line disappears.

The approach that survives works differently: you do not repay debt in general, you repay the portion sitting in the path of a change someone has asked for. Remodelling becomes part of the cost of a feature, defensible because it is attached to an expected result. Less dramatic than a grand programme, and far more likely to outlive a steering committee.

Measure what the next change costs

If the amount of debt is a poor indicator, what should be watched? The useful question is about marginal cost: in which part of the system does a change of comparable size consistently cost more than elsewhere?

• Time from an understood request to production, broken down by business domain.
• Number of components touched by a typical change, and how far they spread across teams.
• Share of incidents concentrated in the same few areas, month after month.
• How long a new team member takes to become autonomous in each part of the system.

These measures point at places, not at quantities. They enable a conversation the financial metaphor makes awkward: the question is not how much the organization owes, but where it is paying, and whether it will keep passing through there.

An expensive area nobody touches any more is not a problem, whatever state it is in. An area the tools call clean but every new feature crosses deserves attention now. That inversion is what makes a technical debt conversation usable by an executive team.