Technical debt is a real liability that appears in no financial statement. It has a principal, it accrues interest, and it eventually has to be repaid or defaulted on. The accounting framework has no category for it, so it is managed — where it is managed at all — on instinct.
Why the metaphor is precise
The term is often used loosely to mean “code I don’t like.” The original formulation was narrower and considerably more useful.
Technical debt is what you incur when you knowingly choose a faster, less complete implementation in order to deliver sooner. Like financial debt, it is a deliberate trade: you receive something now — speed to market, a shipped feature, a met deadline — in exchange for an obligation later.
Also like financial debt, it is not inherently bad. A company that never takes on debt is probably under-investing. A team that never ships anything imperfect is probably too slow. Debt taken deliberately, for a reason, with a plan to repay, is a legitimate instrument.
The distinction that matters is between debt and mess. Debt is a choice made knowingly. Mess is the accumulated result of not knowing better, and it has no corresponding benefit — nobody got anything faster in exchange.
How the interest is paid
The interest is paid in the time every subsequent change takes.
A system with substantial accumulated debt is harder to modify. Changes take longer, require more testing, and break unrelated things more often. This is a continuous cost, it is proportional to how much work is done, and it compounds — because work done under those conditions tends to add further debt.
The observable symptom is a declining ratio of output to effort. A team that shipped substantial features in its first year and struggles to ship small ones in its fourth, with the same headcount and no reduction in ability, is servicing debt. The capacity did not disappear; it was reallocated to overcoming friction.
This is why “we need more engineers” is frequently the wrong diagnosis. Adding people to a high-friction system adds coordination cost and often reduces net output.
Why it accumulates
The incentive structure explains almost all of it.
- Shipping is visible; debt is not. A feature delivered is attributable to a person and a quarter. Debt incurred is diffuse and its cost lands later, on someone else.
- Tenure is shorter than the horizon. The average engineering or product tenure at many organisations is shorter than the period over which serious debt compounds. The people incurring it are frequently not the people who will pay it.
- The cost is invisible until it is severe. There is no gauge. The first clear signal is often a project that takes three times its estimate, by which point the accumulation is years deep.
- Repayment produces nothing demonstrable. A quarter spent on refactoring delivers no feature to show. It is the hardest work to justify and the easiest to defer.
What actually works
Make it visible in ordinary terms. Not “the code is bad” but “this change takes six weeks and would take two in a system without this constraint.” Time and money are the units decisions get made in. Engineering quality is not.
Repay opportunistically, not in campaigns. Large dedicated refactoring projects have a poor record — they are high-risk, deliver nothing incrementally, and get cancelled when priorities shift. Improving each area as it is worked on concentrates effort where it produces the most benefit, because the code being touched most often is where friction costs the most.
Record it when it is incurred. A short note at the moment of the decision — what shortcut, why, what it will cost to undo — converts an invisible obligation into a tracked one. This is the single cheapest intervention available and almost nobody does it.
Distinguish debt worth carrying. Debt in a stable system nobody modifies costs nothing, because interest is only paid when work is done. Debt in the area under active development is expensive. Repayment effort should follow change frequency, not offensiveness.
The default
The end state of unmanaged accumulation is a system that cannot be changed at acceptable cost or risk. At that point the options are a rewrite — expensive, high-risk, and historically prone to failure — or accepting that the product no longer evolves.
Organisations reaching that point usually did not make a decision to get there. They made a series of individually reasonable decisions to defer, each of which was defensible, and none of which was recorded as incurring an obligation.
That is the argument for treating it as debt rather than as quality. A liability that is never recorded is never managed, and the pattern is a familiar one — the costs that damage organisations are rarely the ones on the income statement.
