technical-debt-management

Technical debt management

Debt is a deliberate trade: taking on future cost to move faster now. Most of what gets called debt

is not that — it is mess, which was never a decision, or drift, where the world moved and the code

did not. The distinction matters because the arguments and remedies differ.

Classify before prioritizing

• Deliberate debt — a known shortcut with a reason. Has a principal and interest. Legitimate.
• Mess — nobody chose it; it accumulated. No trade was made, so there is nothing to defend.
• Drift — the code was right for a context that has changed. Neither shortcut nor carelessness.
• Not debt at all — code someone dislikes, or would have written differently. Taste is not debt,

and rewriting on taste is how remediation budgets get spent with nothing to show.

Cost is a rate, not a total

Debt matters proportional to how often you pay it. Ugly code in a module nobody has touched in three

years costs nothing; a moderate awkwardness in the file every feature crosses costs continuously.

Measure by contact: change frequency, how long changes there take relative to elsewhere, how often

changes there cause incidents, and how many people avoid the area. Overlay change frequency on

complexity and the priorities become obvious and defensible — the expensive parts are where both are

high, which is rarely where intuition points.

Argue in the language of the decision-maker

"The code is bad" loses to any feature request. What wins is the rate: this area consumes a

disproportionate share of delivery time, causes a disproportionate share of incidents, and the gap

widens.

Frame remediation as capacity recovery with a payback period — the same terms as

finance:capital-allocation, which is where any large migration will eventually be judged.

Remediate incrementally

Large rewrites fail at a well-documented rate: they take longer than estimated, deliver no value

until the end, and are canceled halfway leaving two systems. Prefer strangling the old system

gradually behind a stable interface, so value lands continuously and the work can stop at any point

without leaving a mess.

Improve opportunistically where you are already working — the code you are touching anyway is the

cheapest code to improve, and it is by definition the code that is being touched.

Never

• Present debt as a quality argument to someone accountable for delivery dates.
• Prioritize by how bad code looks rather than how often it is paid for.
• Start a rewrite with no value delivered until completion.
• Classify taste as debt.