What is Technical Debt?
Definition
Technical debt is the accumulated cost of shortcuts and expedient design choices in software: work that saved time when it was done but makes every later change slower and riskier. The term comes from Ward Cunningham's financial metaphor, in which the principal is the effort needed to fix the underlying problem and the interest is the extra effort paid on every change until it is fixed. Deliberate debt can be a useful tool; unnoticed debt eventually stalls a project.
Also known as: tech debt, code debt, design debt, legacy code
Principal and interest
Ward Cunningham introduced the metaphor in 1992 while explaining his team's work on financial software: shipping a first version quickly is like borrowing money, and the debt stays outstanding until the code is reworked to reflect what the team has since learned. The useful part is the split between two costs:
- Principal: the one-off cost of fixing the problem, such as consolidating price calculation logic that has been copied into three places.
- Interest: what you pay on every change until then: finding all three copies each time a pricing rule changes, updating them, and chasing the bug when one gets missed.
Interest is only charged when you touch the code. An ugly but stable module that nobody ever changes accrues almost none.
How it accumulates
- Skipped tests and “good enough for now” fixes made to hit a deadline.
- Dependencies left untouched for years, and framework versions past end of support.
- Architecture chosen for day one that no longer fits the size of the product.
- Copy-pasted code, undocumented business rules, setup steps that live in one person's head.
- Changing requirements: a model that was right last year may not match how the business works today. Nobody did anything wrong, yet the debt is real.
Not every defect is debt. A discount calculated wrongly is a bug; the tangled structure that makes fixing that discount take three days is debt.
Deliberate versus inadvertent
Martin Fowler's widely used quadrant asks two questions: was the debt taken on knowingly, and was it taken on prudently?
| Reckless | Prudent | |
|---|---|---|
| Deliberate | “We don't have time for design.” | “We're shipping this for the trade show, we know the cost, and we'll fix it next month.” |
| Inadvertent | A mess created because the team didn't know better. | “Now we understand how we should have built this.” |
Prudent, deliberate debt is a legitimate business decision: writing throwaway code to test a market quickly with a minimum viable product is the textbook case. The trouble starts when the decision is never written down and “later” never arrives.
Warning signs worth tracking
No single number captures technical debt, and static analysis scores only see part of it. The more reliable signals show up in how work flows:
- Tasks of similar size take longer month after month.
- Bugs keep surfacing in the same handful of modules.
- The team avoids touching certain files, or a new developer needs days to get a working setup.
- Releases routinely need manual fixes afterwards.
Logging each known item in the backlog with a concrete statement of its interest (“pricing logic lives in three places; every campaign change costs about a day”) turns a vague complaint into something the business can prioritise.
Paying it down
- Clean as you go: improving the code you are already changing is the cheapest repayment there is, and pull request reviews are a natural place to keep those small steps honest.
- Reserve capacity: a fixed share of every iteration for debt items stops it from being the work there is never time for.
- Tests first: large refactors without unit tests protecting current behaviour tend to convert debt into new bugs.
- Be wary of the big rewrite: starting over is tempting but risks losing business rules nobody documented. Replacing parts incrementally is usually safer.
Some debt is not worth repaying at all. Polishing a feature scheduled for removal, or a stable component no one modifies, is paying off a loan that charges no interest.