Managing Technical Debt

What is Technical Debt?

Technical Debt (or Code Debt) is a metaphor that equates software shortcuts to financial debt. Just as a loan allows you to buy status or property now in exchange for interest later, “dirty” code allow you to ship a feature faster today at the cost of “interest”—the extra effort needed to maintain or modify that code in the future.

The Debt Quadrant (Martin Fowler)

Deliberate & Reckless: “We don’t have time for design.” (High risk, bad culture).
Deliberate & Prudent: “We must ship now and deal with consequences later.” (Strategic, healthy).
Inadvertent & Reckless: “What’s Layering?” (Unintentional, hazardous).
Inadvertent & Prudent: “Now we know how we should have done it.” (Natural learning process).

Strategy for Managing Debt

You cannot simply stop all feature development to “fix everything.” A bridge that is closed for maintenance forever is a useless bridge. Instead, use a structured approach:

1. The Debt Register

Keep a transparent log (in Jira, GitHub, or a Wiki) of known technical debt. Each entry should include:

Location: Which service/module?
Symptom: What is painful? (e.g., “Manual steps in deployment”).
Interest Rate: How much does this slow us down every sprint?
Principal: How long will it take to fix properly?

2. Prioritization Framework

Use a matrix of Impact vs. Effort:

High Impact / Low Effort: Quick wins. Do these immediately.
High Impact / High Effort: These are the “Big Rocks.” Plan these into the roadmap as separate initiatives.
Low Impact / High Effort: Ignore these. They aren’t worth the cost.

3. The 20% Rule

Dedicate roughly 20% of every sprint to “Keeping the lights on” (KTLO) and paying down minor debt. This prevents the debt from accumulating to a point of system bankruptcy.

Practice Exercise

You are the Lead Engineer on a legacy platform. How do you convince a Product Manager that we need to spend two weeks refactoring the Authentication service instead of building a new Dashboard?

Answer

The Pitch: Speaking in Business Value

Product Managers care about Revenue, Speed, and Risk. I would frame the refactor using these terms:

Risk Mitigation: “Our current auth logic is scattered across five files with no unit tests. Every time we change a user permission, there is a 30% risk of breaking login for everyone. Refactoring reduces our Production Downtime Risk.”
Increased Velocity (Speed): “Right now, adding a new login provider (like SAML) takes 4 weeks because of the messy code. After this refactor, it will take one week. We are investing 2 weeks now to save 3 weeks on every future integration.”
The “Opportunity Cost”: “If we build the dashboard on top of this broken auth, the dashboard will also be broken. We will spend more time fixing the dashboard later than we would spend fixing the auth now.”

Quantitative Evidence

Show the Lead Time for recent bugs in that area.
Show the Escaped Bug Rate (bugs found in production vs. testing).
Present a 30-60-90 Day Plan:
- Day 30: Add unit tests to existing mess to ensure safety.
- Day 60: Modularize the logic.
- Day 90: Support the first new feature on the clean code.

Summary

Technical debt is an inevitable part of software development. The goal is not to have zero debt—it’s to have managed debt. By tracking interest rates and communicating in terms of risk and velocity, you can build a sustainable engineering culture that delivers both value and quality.