Technical Debt Is the Wrong Metaphor

Here is the thesis. The metaphor of technical debt is doing active harm, because it imports the grammar of finance into a domain where none of the financial properties hold, and the grammar shapes the decisions. Debt sounds manageable. Debt sounds like a choice with a known cost. Debt sounds like it can be carried responsibly. Most of what teams call technical debt is not any of those things. It is risk with no price attached, and calling it debt is how the price stays unattached.

I am not arguing that the underlying problem is imaginary. The rot is real. I am arguing that the metaphor is the wrong instrument for measuring it, and that the wrong instrument produces the wrong conversations.

What debt actually implies

Real debt has properties that make it a useful concept. The principal is known. The interest rate is known or bounded. The repayment schedule can be chosen. Taking debt is a trade where both costs are priced at the moment of the decision, and the borrower accepts a quantified future obligation in exchange for a present capability.

Now examine the thing we call technical debt. The principal is unknown, because the cost of the rewrite is discovered only during it, and is usually larger than estimated. The interest rate is unknown, because the drag of a bad structure depends on how the system evolves, which nobody can forecast. There is no repayment schedule, because repayment is perpetually deferred in favour of features, indefinitely, without anyone deciding to defer it.

Not one of the financial properties survives contact with the reality. So the metaphor is not an approximation of the situation. It is a misdescription of it, and misdescriptions are not neutral.

What the metaphor buys and who sells it

The metaphor is popular because it is the only vocabulary that makes engineering maintenance legible to finance minded stakeholders, and I want to steelman that honestly. Saying "we are paying interest on debt" gets a refactor approved where "we want to clean up the code" does not. The metaphor is a persuasion tool that works, and teams that have used it to buy real improvement are right that it has value as rhetoric.

But a persuasion tool is not a measurement tool, and the damage appears when the rhetoric becomes the model. Once debt is the model, the conversation becomes about how much debt is acceptable, which is a question with no answer, because the quantity does not exist. Teams then carry "acceptable" levels of something they have never priced, and the carrying feels responsible precisely because the metaphor says debt can be carried responsibly.

The truer metaphor: unpriced risk and options

The situation is better described as risk, and as options, and both descriptions produce better behaviour.

A bad structure is a risk because its cost is contingent on the future. It costs little if the area is never touched again, and it costs a lot if the area becomes hot. That contingency is the defining property, and risk vocabulary handles contingency natively. You do not ask "how much risk is acceptable" in the abstract. You ask which risks are large, which are likely to be triggered, and which are cheap to reduce now, which is exactly the prioritisation question refactoring actually needs.

The options framing adds the second half. Shipping the quick version is buying the option to learn what the product needs before investing in the right structure, and an option has a known premium and an expiry. The metaphor's failure is that teams take the option and never exercise or expire it, holding the quick structure forever while calling the holding cost interest. Options vocabulary at least contains the expiry date, which debt vocabulary hides.

The behavioural difference

Metaphors are judged by the behaviour they produce, and the two vocabularies produce different behaviour.

Debt vocabulary produces balance sheet thinking: tolerate a level, report a level, occasionally pay it down in a lump. It produces the quarterly "debt sprint", which is the repayment schedule that real debt has and that the metaphor cannot enforce, so the sprint ships the easiest cleanup, not the highest value one.

Risk vocabulary produces inspection and hedging: find the structures whose failure or drag would matter most, estimate the trigger likelihood from where the product is going, and reduce the ones where the expected cost exceeds the fix cost. It produces continuous small refactors in the hot paths, which is what actually keeps a codebase cheap, because the hot paths are where the contingency resolves.

I have watched the same codebase be managed under both vocabularies, and the risk managed one got cheaper to change while the debt managed one got a cleaner report. The report is not the codebase.

The counterargument, one more time

The honest defence of debt is that organisations need a shared shorthand, and debt is the shorthand available, and replacing it with risk vocabulary requires teaching stakeholders a new language, which is a cost. I accept the cost. I am only pointing out that the shorthand is actively misleading, that it makes deferral look like prudence, and that the teaching cost is paid once while the misleading is paid every planning cycle.

The rule of thumb

Stop asking how much technical debt you have, because the quantity does not exist. Ask instead which structures would cost the most if the product moves the way it is likely to move, and fix those continuously, in the hot paths, as small bets.

Name the quick version an option with an expiry when you ship it, and let the expiry force the decision the debt metaphor defers forever. The metaphor you choose is the conversation you get, and the conversation you get is the codebase you end up with.

The same "the metric hides the contingency" lesson appears in coverage, in code coverage is a marketing metric, and in the abstraction cost, in the cost of abstraction in debugging.

Published on debugly.dev by Rohit Bhadani | Founder of Krova Cloud