Technical Debt - Understanding the Metaphor
Ward Cunningham introduced the term "technical debt" to explain something to business stakeholders: shipping messy code is like taking out a loan.
You get something now (faster shipping), but you pay for it later (slower development). And like financial debt, it compounds.
The metaphor is powerful. But it's often misused. Let's get it right.
Principal, Interest, and Bankruptcy
Principal is the shortcut you took. You hardcoded a value. You copy-pasted instead of extracting. You skipped the test.
Interest is the cost of every future change. That hardcoded value? Now it's in 47 places. That copy-paste? Now you fix bugs twice. That missing test? Now you're afraid to refactor.
Bankruptcy is the rewrite. The codebase is so tangled that you can't change it anymore. You have to start over. This is catastrophically expensive and usually fails.
Types of Technical Debt
Not all debt is the same. Martin Fowler identifies a useful 2x2:
| Reckless | Prudent | |
|---|---|---|
| Deliberate | "We don't have time for design" | "We must ship now and deal with consequences" |
| Inadvertent | "What's layering?" | "Now we know how we should have done it" |
Deliberate + Prudent: You know you're taking a shortcut. You have a plan to pay it back. This is often acceptable.
Deliberate + Reckless: You know it's wrong and you don't care. This is negligence.
Inadvertent + Prudent: You did your best, but learned better approaches later. This is inevitable.
Inadvertent + Reckless: You didn't know enough to realize you were creating debt. This is a skills gap.
The first and third types are part of healthy engineering. The second and fourth are problems to fix.
When Debt Is Acceptable
Debt is a tool. Like financial debt, it can be used strategically:
Acceptable debt:
- Prototypes that will be thrown away (not "productionized")
- One-off scripts that run once
- Time-sensitive opportunities where shipping matters more than perfection
- Experiments where you're testing an idea, not building forever
Unacceptable debt:
- Core business logic (the stuff that makes you money)
- Security-critical code (the stuff that loses you money when it fails)
- Long-lived systems without a plan to pay down the debt
- Any debt taken without awareness ("we'll figure it out later")
The key question: Do you have a plan to pay it back?
If yes, you're making a strategic decision. If no, you're gambling.
Tracking Debt
Debt you don't track doesn't get paid. It just accumulates interest.
Ways to track:
- Debt backlog — A dedicated backlog of known debt items, separate from features
- TODO comments with tickets —
// TODO(JIRA-123): Replace hardcoded timeout - Debt spikes — Periodic time allocated specifically to pay down debt
- Metrics — Track bug rate, time-to-fix, deployment frequency
The goal is visibility. When stakeholders ask "why is this taking so long?", you can show them the debt ledger.
The Compound Interest Problem
Here's what makes debt dangerous: it compounds.
- Week 1: Hardcode one config value. Cost: 5 minutes saved.
- Week 4: Hardcode three more values in the same pattern. Cost: 15 minutes saved.
- Week 12: 47 hardcoded values across 23 files. Cost to change any of them: 4 hours.
- Week 24: Nobody remembers all the places. Changes cause production incidents.
The debt didn't grow linearly. It grew exponentially. And unlike financial debt, there's no clear monthly statement showing you how much you owe.
Paying It Down
Debt repayment strategies:
- Boy Scout Rule — Pay down small debt continuously (previous lesson)
- Debt Sprints — Dedicate every 4th sprint to tech debt
- Strangler Pattern — Replace messy code incrementally as you work near it
- Investment Allocation — 20% of every sprint goes to debt and infrastructure
The wrong approach: waiting until you "have time." You never have time. Debt grows until it forces a crisis.
Communicating with Stakeholders
Technical debt is not interesting to business stakeholders. Interest payments are.
Don't say: "We need to refactor the user service."
Say: "New features in user management are taking 3x longer than they should. We estimate 2 weeks of cleanup would save 6 weeks over the next quarter."
Frame it in terms they understand: time, money, risk.
Key insight: Technical debt is a loan against your future velocity. Track it. Plan to pay it back. Distinguish strategic debt (conscious decisions) from accidental debt (mistakes and ignorance). Never take debt without a repayment plan.