- Technical debt's real cost shows up as declining shipping speed, not a line item.
- Some debt is a reasonable, deliberate trade-off — the danger is debt taken on by accident.
- A codebase nobody wants to touch is a strong signal debt has compounded too far.
- Paying down debt in small, continuous increments beats a single, risky 'big rewrite.'
The invoice that never arrives
Technical debt doesn't show up as a bill — it shows up as every subsequent feature taking a little longer to ship than it should, for reasons nobody can quite point to. That gradual slowdown is the real cost, and it's easy to miss because it never arrives as a single, attributable expense.
Some debt is a reasonable trade-off
Taking a shortcut to hit a real deadline, with a conscious decision to revisit it later, is a legitimate and often correct engineering trade-off. The problem isn't debt itself — it's debt taken on unconsciously, without anyone deciding it was worth the trade, which accumulates without anyone tracking it.
The tell: nobody wants to touch a certain part of the code
When a team consistently avoids working in a specific module or routes around it rather than through it, that avoidance is a strong, visible signal that debt has compounded there past a healthy point — worth investigating specifically, not just noting generally.
Small, continuous paydown beats a big rewrite
The instinct to fix accumulated debt with one large rewrite project is usually the riskier and more expensive path — big rewrites often take longer than planned and introduce new bugs. Continuous, smaller refactoring done alongside regular feature work keeps debt from compounding without the risk of a large, disruptive project.
Track it like you'd track any other risk
Teams that explicitly track known debt — a running list, reviewed periodically — make better decisions about when to pay it down versus when to accept it a while longer. Debt that's invisible because nobody's tracking it is debt that silently grows until it forces an expensive, unplanned fix.