Five Tech Debt Interest Mistakes
The errors that make compounded-cost math look exaggerated or irrelevant.
Bad inputs make the tool a meme. Good inputs make it a scheduling weapon.
Tech Debt Interest can be abused to justify any refactor if you stretch growth rates. It can also be ignored if applied to the wrong code. The five errors below are the most common ways the number misleads.
Quick answer
Bad inputs make the tool a meme. Good inputs make it a scheduling weapon.
Key points
- ▸ Overestimating growth rate. 15-20%/month compounds into absurd numbers. Real active code averages 5-10%/mo; stable code is 1-3%.
- ▸ Applying to dead code. Code nobody touches doesn't compound. Debt in unmaintained modules stays the same size — fix only if the module is reactivated.
- ▸ Ignoring velocity. A 6-hour fix in a 20-feature-per-month module compounds far faster than the same fix in a 1-feature-per-month module. Set velocity honestly.
- ▸ Treating the number as exact. Payoff hours are order-of-magnitude. Don't argue about 22 vs 24 — argue about 22 vs 6 or 22 vs 140.
- ▸ Missing the opportunity cost of not refactoring. Debt repayment usually unlocks feature velocity. Fix + velocity-unlock often beats raw compounded payoff as the ROI case.
- ▸ Forgetting compounding works for refactors too. A partial cleanup now reduces future compounding. Even incremental debt work beats waiting for a "rewrite window."
Examples
- The growth-rate inflationEngineer sets growth to 20%/mo, gets 400-hour payoff number, loses credibility. Realistic 8%/mo gives 22 hours — equally compelling, actually defensible.
- The dead-code misapplicationDebt in a deprecated service. Velocity is 0. Payoff stays flat at initial fix. Don't spend time fixing it — the debt is frozen.
- The exactness trapTeam debates whether payoff is 22 or 28 hours. Real point: the hack saved 4 hours, compounded payoff is 5-7× that. Book the refactor and move on.
When to use which tool
- Tech Debt InterestUse 5-10%/mo for active code, 1-3% for stable, 0% for dead. Treat output as ranged, not exact.Quantify the compounding hours to fix a shortcut as the codebase grows on top of it. Maintenance heatmap.
- Revenue per HeadWhen debt repayment competes with hiring, compare marginal value of each path using both tools.Estimate whether the next hire raises or lowers revenue per employee after management time and ramp-up.
Related
- Tech Debt InterestQuantify the compounding hours to fix a shortcut as the codebase grows on top of it. Maintenance heatmap.
- Revenue per HeadEstimate whether the next hire raises or lowers revenue per employee after management time and ramp-up.
- What Tech Debt Interest CalculatesThe hours it will take to fix a shortcut in 6, 12, or 18 months — compounded by everything built on top of it.
- When to Run Tech Debt InterestFive engineering moments when the compound cost number actually changes scheduling.
Frequently asked questions
› What growth rate for a codebase in active redesign?
If the debt sits in code about to be replaced, growth is effectively 0 — the rewrite absorbs the debt. Don't double-count.
› How do I handle debts that interact with each other? How-to
Model them separately and add caution: entangled debts often require a single larger refactor, not sequential fixes. The combined payoff is usually bigger than the sum.
› How should I use a decision framework in real life? How-to
Use a decision framework to expose the tradeoff, not to outsource the decision. Write down the inputs, compare the output with your constraints, then ask what would change the answer. The strongest use is scenario testing: base case, conservative case, and failure case.
› Is this financial, legal, or tax advice? Trust & accuracy
No, this is not legal, financial, tax, medical, or professional advice unless the page explicitly says that use case is supported. It organizes assumptions so you can inspect them. Verify high-stakes choices with qualified people who can review facts, contracts, regulations, and downside risk.
› What assumption matters most in a decision model? Edge case
The most important assumption is usually the one you are least certain about and most emotionally attached to. Change that input first. If the recommendation flips after a small change, the decision is fragile and needs more evidence before you treat the model as useful.