Anyone who wants to measure technical debt first encounters a problem with its definition. The term was coined in the 1990s by Ward Cunningham and originally described the extra cost a team pays later on for making quick decisions today. In practice, this quickly becomes a gut feeling: The code is old, no one dares to touch certain modules, and every change takes longer than it should. But a hunch isn’t enough to justify a budget. Anyone who wants to request funding for refactoring in the next annual plan needs figures that will stand up to scrutiny by management and can be compared to the previous year’s budget.
Measuring technical debt means comparing the estimated effort required to resolve it to the total development costs. In practice, the Technical Debt Ratio and the SQALE model—as implemented by SonarQube—are used for this purpose. Both metrics only become meaningful over the course of several quarters. This metric alone is not sufficient for budgeting purposes, but it does serve as a starting point for discussions with management.
The Actual Cost of Technical Debt
The scale of the problem was examined by McKinsey in a 2020 survey of technology leaders. According to that McKinsey survey (2020), 10 to 20 percent of the budget for new products goes into remediating technical debt. The same 2020 survey puts the stock of technical debt at 20 to 40 percent of the value of the entire technology estate. 60 percent of the CIOs surveyed by McKinsey in 2020 saw an increase over the previous three years. According to the same survey, companies with active debt management reported up to 50 percent more time for work that actually creates value, rather than for ongoing maintenance.
According to the McKinsey survey, this much of the budget for new products goes toward paying off technical debt rather than developing new features.
McKinsey, 2020
These figures come from a survey of executives, not from a technical analysis of individual codebases. They serve as a rough guide to the order of magnitude. They are not suitable as target values for your own company.
Measuring Technical Debt: These Metrics Matter
A common metric is the technical debt ratio, which is the ratio of the costs of resolving technical debt to total development costs. According to an analysis by Sourcegraph from 2024, a value in the low single-digit percentage range counts as healthy. According to that 2024 analysis, the trend over several quarters matters more than the absolute value. A team whose ratio rises from 3 to 6 percent has a problem, even if 6 percent still looks unremarkable in isolation.
Another widely used model is the SQALE model, as implemented by the SonarQube analysis software. It converts violations of predefined quality rules into an estimated resolution time and compares this to the estimated development time for the entire project. The result is a metric that can be compared over time, as long as the set of rules behind it isn’t constantly changing. If the team switches tools or rules, comparability is lost. This is precisely where the method’s weakness lies.
| Criterion | Technical Debt Ratio | SQALE Model |
|---|---|---|
| Basis for Calculation | Remediation costs relative to development costs | Estimated remediation time for rule violations relative to development time |
| Guideline | A low single-digit percentage range is considered healthy | Not an absolute benchmark, just a comparison within the same set of rules |
| Significance | Trend over several quarters | Trend with an unchanged rule set |
| Comparability ends | when the cost estimate changes within the team | when a tool or set of rules is changed |
Where Key Metrics Reach Their Limits
The Technical Debt Ratio and the SQALE model measure what an analysis tool can detect: duplicate code, overly complex functions, missing tests, and outdated patterns. Architectural decisions that only come back to haunt the company years later—such as an improperly defined module boundary or a database built for a different load profile—fall through the cracks. The same applies to knowledge that leaves the company along with a single employee.
A team can report a ratio of 2 percent and still be stuck with a system that only one person understands. Anyone who wants to measure technical debt should therefore document such blind spots in writing alongside the metric. Metrics are a starting point for discussions with management; they are not a substitute for those discussions. Anyone presenting a figure should therefore also be able to name the two or three systems where, based on their own experience, the figure is too low. The article shows at what point modernization becomes more worthwhile than continued patching. Modernize or Replace Legacy Software? A Decision Tree.
Prioritize the refactoring budget
A rule of thumb helps with prioritization: Sort modules by frequency of changes and error rate, not by individual developers’ subjective sense of what feels off. A module that’s rarely touched but still looks messy can be left as is. A module that undergoes changes every week and produces an above-average number of errors belongs at the top of the list. In practice, these are often core modules such as pricing, inventory posting, or order processing—precisely the areas where errors have the most costly consequences.
Where part of the debt stems from AI-generated code, it’s worth taking a separate look at the risks posed by such code sections before setting priorities, because security vulnerabilities can be masked by ordinary code clutter in those areas. Allocating 10 to 20 percent of the development budget to ongoing debt repayment is a realistic starting point, as suggested by McKinsey’s 2020 figures. Companies with particularly legacy core systems tend to fall toward the upper end of this range.
The McKinsey figures are based on a survey of executives, not on an analysis of individual codebases. They are useful as a rough estimate, but not as a target for your own company. Furthermore, the Technical Debt Ratio and SQALE only capture what an analysis tool can detect. An improperly defined module boundary and knowledge that leaves the company along with a single employee remain invisible in both metrics.
Interpreting Your Own Metrics in Context
A technical debt ratio of 6 percent means very little for a module that is rarely modified, but a great deal for a core system with a high rate of change. A discussion about the affected modules helps put your own figure into perspective before the next budget round.
Frequently Asked Questions
How do you measure technical debt without a tool?
Even without any specific tools, the current state often reveals itself through two symptoms. First, time. Does a small change take significantly longer today than it did a year ago, even though the team hasn’t gotten any smaller? Second, avoidance behavior. Are there files or modules that developers prefer to avoid during planning because no one knows exactly what will happen if they touch them? If you openly discuss both questions with the team and review the answers every few months, you’ll get a useful picture of the situation—even without SonarQube or similar software.
How much of the budget should be allocated to refactoring?
A range of 10 to 20 percent of the development budget for new products aligns with what McKinsey observed among the companies surveyed in 2020. However, this is not a suitable fixed figure. A new product with little accumulated code requires significantly less, while a ten-year-old core system with a high rate of change tends to need more. Rather than a fixed percentage, it makes more sense to use an amount linked to the measured technical debt ratio, which is renegotiated during each budget cycle.
How can you tell when refactoring is coming too late?
A clear warning sign is when estimates for new features are regularly more than double the actual effort, because no one can predict in advance what a change in the existing code will trigger. A second sign is staff turnover concentrated among the teams working on the most problematic parts of the system. When both of these signals occur together, a single refactoring sprint is no longer sufficient. In that case, a program lasting several months with its own budget becomes necessary.
torck develops Custom Software for industry and commerce, often on legacy systems where technical debt has accumulated unnoticed over the years. The development teams in Maxhütte-Haidhof, Vienna, and Rabat regularly take on such codebases and know exactly where a metric will be helpful during the next budget meeting—and where it will merely generate paperwork. Our contractual partner is the German company torck GmbH, which provides the necessary commitment for multi-year refactoring programs. Anyone who needs an assessment of their own technical debt can do so in a Initial Consultation .
German 
English 
French