Technical Debt Interest
Why technical debt does not stay the same cost. How it compounds, accelerates, and why deferring paydown is more expensive than it appears.
The Financial Debt Analogy
Ward Cunningham, who coined the term technical debt, described it as analogous to financial debt. When you borrow money, you pay interest on it. Similarly, technical debt accrues interest in the form of extra effort required to work around poor code.
The critical insight is that technical debt interest is not linear. A system with 10% of its codebase in poor condition does not pay 10% more in maintenance costs. Complexity interactions mean that poor code in critical paths can disproportionately affect the entire system. The coupling problem grows geometrically, not linearly.
This is why many engineering teams report that the second half of their sprint is less productive than the first, and why teams with high debt often feel like they are running faster just to stay in place.
5-Year Cost Projection at 18% Annual Growth
Based on 18% annual debt cost growth rate (typical for codebases with moderate debt). Use the calculator on the home page for your specific compound rate.
What Drives the Compound Rate
As systems grow, poorly structured code develops more dependencies. Each new feature has to navigate the existing complexity, creating new coupling. This makes future changes touch more files, increasing risk and cost.
New engineers must learn the codebase before they are productive. High-debt codebases have steeper onboarding curves. A team that doubles headcount may see only 50-70% productivity gain due to documentation debt and architectural opacity.
Libraries and frameworks that are not updated diverge from current versions. Each major version skipped makes the eventual upgrade more expensive. Security vulnerabilities in outdated dependencies create incident costs.
Without tests, refactoring is risky. Without refactoring, debt accumulates. Low test coverage creates a self-reinforcing cycle: engineers are afraid to clean up because they cannot verify they have not broken anything.
When core systems are fragile, engineers build workarounds instead of fixing root causes. Workarounds accumulate on top of each other, creating layers of complexity that eventually become unmaintainable.
The Debt Cliff
Most teams manage to continue shipping despite growing debt. The danger point is the debt cliff: where the compound interest on debt exceeds the team's capacity to pay it down through normal velocity. At this point, the only options are:
- ●A significant pause in feature development for a debt repayment push
- ●Hiring additional engineers to both maintain current pace and pay down debt
- ●A full or partial rewrite, which carries its own massive risk
- ●Accepting permanent degradation in velocity and quality
This is why the most important time to address technical debt is before it reaches the cliff. Use the calculator to quantify the cost now and build a business case for paydown before it becomes a crisis.