By Arjun Mehta, Principal Engineer at Glue
I have spent twelve years as an engineer watching technical debt accumulate in systems I built, systems I inherited, and systems I was brought in to rescue. The conversations about technical debt are always the same: engineering says "we need to fix this," leadership says "not now, we have features to ship," and the debt grows quietly until it becomes a crisis. The missing ingredient in every one of these conversations is data. These technical debt statistics tell the story that anecdotes cannot.
When you can put a number on the problem, the conversation changes. This post compiles the most important statistics about technical debt, organized by impact area, with context for what each number means in practice.
The Scale of the Problem
Technical debt is not a niche concern. It is an industry-wide condition affecting virtually every software organization.
The Stripe Developer Coefficient report estimated that technical debt costs the global software economy approximately $85 billion annually. That number represents the aggregate productivity loss across the entire industry: engineers spending time on workarounds, maintenance, and rework instead of building new capabilities.
To put that in organizational terms: the same Stripe report found that developers spend approximately 33% of their time dealing with technical debt and maintenance. For a team of 50 engineers at an average fully loaded cost of $200,000 per year, that represents $3.3 million annually going to debt service rather than feature development.
Jellyfish's 2025 research narrows the range to 23% to 42% of developer time spent on debt and maintenance. The variance depends on the age and complexity of the codebase, the organization's investment in debt reduction, and how aggressively the team has shipped features at the expense of code health.
Kong's 2023 survey puts the budget impact at roughly 40% of IT budgets consumed by technical debt. When CIOs report that nearly half their budget goes to keeping the lights on rather than innovation, that is technical debt in financial terms.
These are not edge cases. These numbers represent the median experience across the industry. Your organization's numbers may be better or worse, but if you have never measured, you are likely closer to the worse end. For strategies to make this debt visible, see our guide to technical debt visibility.
Impact on Speed and Morale
The financial numbers are compelling for leadership. The speed and morale numbers are compelling for everyone else.
Development velocity degrades over time. The most insidious effect of technical debt is that it slows everything down, gradually and invisibly. Adding a new feature to a clean module might take two days. Adding the same feature to a module laden with debt, tangled dependencies, and missing tests might take two weeks. The feature is the same. The effort is 5x because the foundation is crumbling.
Research from Capers Jones, one of the most cited figures in software engineering economics, shows that poor code quality can increase development costs by up to 300% over the lifecycle of a system. That is not a typo. Debt does not just add to costs. It multiplies them.
Engineers leave because of debt. A 2024 Stack Overflow developer survey found that developer experience factors, including code quality and tooling, are among the top reasons engineers consider changing jobs. Working in a codebase full of technical debt is demoralizing. Every task takes longer than it should. Every change carries risk. Every sprint feels like running through mud.
Gloria Mark's research at UC Irvine found that the average engineer takes 23 minutes to refocus after each interruption. In debt-laden codebases, interruptions are more frequent because engineers need to consult teammates about undocumented behavior, workaround patterns, and fragile modules. The compounding effect of debt-driven interruptions on daily productivity is substantial.
On-call burden increases. Production incidents are technical debt making itself known. Systems with high debt have more bugs, more outages, and more midnight pages. The operational burden falls disproportionately on senior engineers, the people you can least afford to burn out. Tracking the relationship between debt levels and incident frequency is one of the most persuasive arguments for technical debt reduction investment.
The morale dimension is hard to quantify but easy to observe. Ask your engineers how they feel about the codebase. If the answer involves profanity, you have a debt problem.
Financial Impact
Leadership speaks in dollars. If you want technical debt addressed, translate the impact into financial terms.
The PMI Pulse of the Profession report found that $109 million is wasted per $1 billion invested in software projects. While not all of that waste is attributable to technical debt, debt is a significant contributor through its effects on estimation accuracy, rework rates, and delayed delivery.
Each spec error caused by misunderstanding the codebase costs approximately $75,000 per year according to Capers Jones research. When PMs write specifications without codebase context, the resulting rework from specs that conflict with system reality compounds across every project.
The Standish Group reports that 66% of software projects have cost overruns. Technical debt contributes to these overruns in two ways: it increases the actual effort required for feature work, and it makes estimates less accurate because teams cannot gauge the true complexity of debt-laden modules.
Developer recruitment costs amplify the problem. When engineers leave due to poor code quality, the replacement cost is significant. Industry estimates for replacing a senior engineer range from 1x to 2x annual salary when you factor in recruiting, onboarding, and the productivity gap during ramp-up. Cortex estimates the cost at approximately $240,000 per senior developer. In organizations with high technical debt, turnover is higher, creating a compounding cost spiral.
For CTOs making the case for debt reduction to the board, the financial framing is essential. "We need to refactor the payment system" gets pushback. "We are spending $1.5 million per year in engineering capacity on workarounds in the payment system, and addressing the root cause will cost $300,000" gets a budget allocation.
Industry Benchmarks
How much technical debt is normal? The honest answer is that there is no universally agreed benchmark, but the data provides useful reference points.
23-42% of developer time on maintenance: This range from Jellyfish represents the typical allocation across the industry. If your team is at the low end, you are managing debt well. If you are at the high end, debt is materially affecting your delivery capacity.
20% allocation for debt reduction: Many high-performing engineering organizations dedicate approximately 20% of sprint capacity to debt work. This is not a universally agreed number, but it appears consistently in engineering management literature as a sustainable allocation that balances feature delivery with system health.
Less than 24-hour PR review cycle time: While not directly a debt metric, review cycle time correlates with codebase health. Debt-laden modules produce larger, more complex PRs that take longer to review. If your average review cycle time is climbing, it may be a signal of increasing debt.
Fewer than 2 production incidents per service per month: Again, not a pure debt metric, but incident frequency tracks with debt levels. Systems with unaddressed debt tend to have higher incident rates.
Code coverage above 70%: Low test coverage is both a form of technical debt and an enabler of more debt. Without tests, engineers are reluctant to refactor, which means debt accumulates faster. Teams with coverage above 70% tend to address debt more actively because they have the safety net to do so.
Glue helps organizations measure their technical debt by analyzing codebase complexity, dependency tangles, knowledge concentration, and code health indicators across the entire system. Instead of relying on engineering surveys or gut feelings, you get continuous, objective measurement of where debt lives and how it is trending. This data turns the annual "should we invest in debt reduction?" debate into a quarterly, evidence-informed planning discussion.
Technical debt is not optional. Every growing software system accumulates it. The question is whether you manage it with data and intention, or whether you let it manage you through missed deadlines, burned-out engineers, and mounting maintenance costs. The statistics are clear: the cost of ignoring debt compounds faster than the cost of addressing it.
FAQ
How much time do developers spend on technical debt?
Research from Jellyfish shows that developers spend between 23% and 42% of their time on technical debt and maintenance tasks rather than building new features. The Stripe Developer Coefficient report places this figure at approximately 33%. For a team of 50 engineers, this represents millions of dollars annually in capacity diverted from feature development to debt management. The exact percentage depends on codebase age, organizational investment in code health, and how aggressively the team has prioritized shipping over maintenance.
What is the business cost of technical debt?
Technical debt costs the global software economy approximately $85 billion per year according to Stripe. At the organizational level, Kong's research shows that technical debt consumes roughly 40% of IT budgets. Additional costs include higher engineer turnover (replacement cost of $240,000+ per senior developer), increased production incidents, and estimation inaccuracy that leads to the 66% project cost overrun rate reported by the Standish Group. The financial impact compounds over time as debt accumulates.
How do you measure technical debt?
Measure technical debt through a combination of code quality metrics (complexity, test coverage, dependency counts), developer surveys (time spent on workarounds, confidence in making changes), and operational data (incident frequency, mean time to recovery, PR review cycle time). Advanced approaches use tools like Glue that analyze the entire codebase to surface debt indicators including knowledge concentration risk, high-churn modules with low test coverage, and tangled dependency chains. The most effective measurement combines automated analysis with qualitative engineering input.