Technical debt is discussed as a moral failing, which makes it hard to reason about. Treated as borrowing — a deliberate trade of future cost for present speed — it becomes a decision you can evaluate, and sometimes the right one.
Deliberate debt is often correct
Shipping a hardcoded rule to test whether anyone wants the feature is sound engineering. If nobody wants it, you saved the general implementation entirely. The failure is not taking the shortcut — it is taking it without recording it, so nobody knows the loan exists.
The problem is rarely the shortcut. It is the shortcut nobody wrote down.
The kind that compounds
Not all debt accrues interest. A slightly awkward module nobody touches costs nothing. Debt in the code every feature must pass through — the core model, the auth layer, the deployment pipeline — taxes every future change. Location matters far more than severity.
Make the case in business terms
'The code is messy' does not get funded. 'This module is why every change to checkout takes three days instead of one, and we shipped two incidents from it last quarter' does. Instrument change failure rate and cycle time by area so the argument comes with evidence rather than aesthetics.
Repay in the course of the work
Large refactoring projects with no feature output are hard to fund and easy to cancel halfway. Improving the specific area you are already touching for a feature is nearly invisible in scheduling terms and compounds steadily. Reserve dedicated projects for debt too large to address incrementally.
Some debt should never be repaid
Code in a product line being sunset, a service due for replacement, a feature used by four customers — cleaning these is effort with no return. Deciding not to fix something is a legitimate and underused outcome, and it frees attention for debt that actually costs you.
Keep a register
A simple list of known shortcuts, what each will cost, and what should trigger repayment — 'when this exceeds 10,000 users', 'when we add the second currency'. This converts folklore held by whoever has been there longest into something a team can prioritise, and it survives that person leaving.
