Debt is a metaphor about interest
The useful part of the metaphor is that debt costs you repeatedly. Code that is imperfect but stable, rarely touched, and well isolated charges no interest — it just sits there. Paying it off is spending real money to remove a payment you weren’t making.
The test is how often you touch it
Debt in code you change weekly taxes every change and compounds. Debt in a module untouched for two years costs nothing. Rank by change frequency and the priority order usually looks nothing like the team’s list of things they dislike.
Code you never touch isn’t debt. It’s just old, and old is not a defect.
Three kinds worth paying immediately
Anything that makes failures invisible, anything that makes a change risky in a way you can’t test, and anything only one person understands. These raise the cost of every future decision, including the decision to do nothing.
Three kinds worth keeping
Unfashionable-but-working choices, duplication in code that is genuinely diverging, and workarounds for external systems you don’t control. The last is often mislabelled as debt when it is actually a correct adaptation to somebody else’s constraint.
Attach it to work that was happening anyway
Cleanup bundled into a feature in the same area is easy to justify and gets done. A standalone debt quarter competes with customer value and loses, which is why it is usually proposed and rarely funded.
Beware the debt argument for a rewrite
Accumulated debt is the usual justification for replacing a system wholesale, and it is usually the weakest one. The honest test is still whether the next three things the business wants are blocked by the structure — the distinction between a rewrite case and boredom.