The Term Hides Two Very Different Situations
"Technical debt" gets used for both the shortcut that will cost you a production incident next quarter and the shortcut that's been sitting quietly in a module nobody's touched in two years, causing nobody any harm. Treating them the same way — as a debt-reduction backlog to work down uniformly — wastes effort on the second category that would be far better spent on the first.
The Question Is Cost of Carrying vs. Cost of Repaying
Repaying debt has a cost: engineering time, regression risk, opportunity cost against features. Carrying it also has a cost: friction, incident risk, slower onboarding for anyone who touches that code. The right call is whichever cost is lower, evaluated honestly — not an assumption that repayment is always the responsible choice. Sometimes the responsible choice is to leave it and write down why.
Location in the Codebase Changes the Calculus
A shortcut in code that changes every sprint compounds — every new feature built near it inherits the mess, and the cost of fixing it later only grows. The same shortcut in a stable module that nobody has needed to modify in a year is a different problem entirely. It's not accumulating interest. It's just sitting there. Prioritise by rate of change in the surrounding code, not by how uncomfortable the shortcut looks.
Undocumented Debt Is the Dangerous Kind, Not Unpaid Debt
The actual risk usually isn't the debt itself — it's debt nobody remembers exists. A shortcut with a comment explaining what it is and why it was acceptable is a known, managed risk. The same shortcut with no explanation is a landmine for whoever encounters it next, debt or not. If you're deciding to keep something, write down why. That one habit does more for a codebase's health than most repayment sprints.