In 30 seconds
- Shortcuts now create "interest": slower, riskier changes later.
- Some debt is deliberate and fine; unmanaged debt is the danger.
- Pay it down continuously, not in a one-off rewrite.
The metaphor
Ward Cunningham coined the term in 1992. Shipping imperfect code is like borrowing money: it can be smart if it gets you to market sooner, but you pay interest every time you work in that code until you pay the loan back by improving it.
Four kinds of debt
| Reckless | Prudent | |
|---|---|---|
| Deliberate | "No time for design" | "Ship now, fix next sprint" |
| Inadvertent | "What's layering?" | "Now we know how we should have built it" |
This quadrant is from Martin Fowler. Only prudent, deliberate debt is a real choice.
Warning signs
- Small changes take days and break unrelated things
- Only one person dares touch part of the code
- Velocity slowly falls for no visible reason
Paying it down
- Leave code a little better each time you touch it
- Strengthen the Definition of Done so new debt isn't added
- Put larger debt items on the Product Backlog with a clear cost of not fixing them
Myth vs reality
Myth · All technical debt is bad.
Reality · Deliberate, tracked debt can be a sound business choice.
Myth · A rewrite clears the debt.
Reality · Rewrites often recreate the same debt; incremental refactoring is safer.
Myth · Debt is purely a developer problem.
Reality · It slows the whole product, so the Product Owner should see and order it.
The AI angle
AI makes it cheap to add code, including code nobody fully understands. It can also speed up paying debt down. Which happens depends on your review and refactoring habits.
FAQ
How do we explain debt to non-engineers?
Use the interest metaphor: every new feature costs more until we pay it down.
How much time should go to debt?
Many teams reserve a steady slice, such as 10-20% of each sprint.
Is technical debt the same as bugs?
No. Bugs are wrong behaviour; debt is code that works but is costly to change.