Not all technical debt is bad. Pretending it is, is the problem.
Debt is a tool. A startup that ships a hacky prototype in a weekend to validate the idea is taking on debt deliberately, because shipping matters more than correctness. A large company running an unsupported version of a database because the upgrade path is complicated has also taken on debt, except nobody chose to. Both situations involve technical debt. Only one is a problem.
The four kinds of debt
Ward Cunningham coined the term in 1992. Martin Fowler later classified it. A useful distillation:
Deliberate and prudent. "We know this is not the right design, but we will ship it now and fix it in three weeks." Acceptable and often correct.
Deliberate and reckless. "We know the right design. We have time to do it. We are choosing not to." Rare to admit, common in practice.
Inadvertent and prudent. "We shipped what we thought was the right design. Six months later we know better." Inevitable and not blameworthy.
Inadvertent and reckless. "We did not think about design at all. We just shipped." The worst kind. Compounds fastest.
Most debt in most codebases is some mix of kinds three and four. The team did what seemed right at the time. The codebase grew. The original decisions aged poorly. Nobody is to blame. The debt still exists.
Why debt compounds
A healthy house needs occasional maintenance. A neglected house needs much more. Code is the same.
Small debts attract larger ones. A file with one hack is easier to add a second hack to than to refactor. Nobody wants to be the one who breaks the streak.
Tests lag behind. Debt-heavy code is often debt-heavy because the original author did not write tests. Adding tests later requires understanding the code, which is harder than when it was fresh.
Context drains out. Over months, the people who wrote the code leave, change roles, or simply forget. What was a "clear" hack becomes an inscrutable relic.
Knowledge silos form. One engineer becomes the only one who knows how a module works. That engineer cannot go on holiday without something breaking.
Debt's compounding is the reason "we will fix it next quarter" rarely works. By next quarter, the fix is harder.
How to prioritise
The wrong approach: list every piece of debt and try to eliminate all of it. You will never finish.
The right approach: combine two signals.
Change frequency. How often does this code change? Git log tells you. Debt in code that rarely changes costs little. Debt in code that changes weekly costs a lot.
Blast radius. How many other modules depend on this one? If fixing it affects ten files, it is expensive. If fixing it affects one, it is cheap.
The best debt to pay is in code that changes frequently and has small blast radius. Quick wins that compound into freer future work.
The worst debt to pay is in code that rarely changes and has large blast radius. High cost, low return. Leave it unless it becomes a security issue.
A practical cadence
Teams that successfully manage debt tend to share a pattern:
10 to 20% of capacity allocated continuously to debt reduction. Not "debt sprints" once per quarter. Steady work alongside features.
Every PR should leave the codebase slightly better. Not every PR has to be a refactor. Most do not. But a PR that introduces new complexity without any compensating improvement is a regression.
Weekly review of metrics. File size distribution, complexity, duplication, change coupling. When a trend turns wrong, the team discusses it before it becomes dramatic.
Quarterly reviews of architectural debt. The bigger stuff. Legacy modules that need restructuring. Old APIs that need deprecation. Not every quarter produces a decision, but the conversation is had.
The role of tools
Debt tracking is not what debt tools should do. A Jira ticket labelled "tech debt" that nobody reads is worse than useless. What tools should do:
- Make the trend visible. Quality scores over time. Complexity over time. Coupling over time.
- Fail CI when debt grows. Gates that prevent additions rather than trying to remove what is already there.
- Surface the specific findings attached to specific files, not a backlog list.
Debt you can see gets addressed. Debt in a spreadsheet accumulates.
The principle
The worst outcome is not having debt. It is having debt you do not know about, in code you rarely look at, compounding quietly until it forces a crisis.
Visibility first. Prioritisation second. Consistent action third. Do the cheap, high-return debt continuously. Leave the rare, large-blast-radius debt alone unless it becomes urgent. Measure the trend so you know whether the situation is stable.
Debt is fine. Unknown, unmanaged, compounding debt is not.
