Tech Debt Measurement Frameworks
Last updated . Sources are named and dated inline - how we source claims.
A reference to the named frameworks. What each one measures, what it is good for, and where it misleads.
SQALE, ISO 25010, the Technical Debt Ratio, the Maintainability Index, SPACE, DORA-as-a-framework, and the OMG automated measure - plus the tools that implement them, and four modelling dimensions of our own.
What This Page Covers
This page covers WHICH framework to adopt. It is a reference, not a how-to. Each entry answers the same three questions: what does this framework actually measure, what is it good for, and where does it mislead you? It does not explain how to collect a metric, and it does not define the DORA metrics - it links to the page that does.
For HOW to measure
What to instrument, where the raw data lives, collection cadence, and the full definition of the five DORA delivery metrics. See Measuring Tech Debt.
For WHAT TO BUILD
Dashboard layout, tile anatomy, refresh cadence, audiences, and what to do when a number moves. See Metrics Dashboard Guide.
How to Choose a Framework
A framework is not a metric. A metric is a number; a framework is an opinion about which numbers matter, how they combine, and what a combined score means. Choosing one is therefore mostly a question of what you need the number to survive - a sprint retrospective, a procurement review, or a regulator.
Start from the question you have to answer. "How much debt do we have?" wants a principal estimate, which means SQALE or the Technical Debt Ratio. "Which quality dimension is suffering?" wants a taxonomy, which means ISO 25010. "Are we getting better at delivering?" wants DORA. "Why does working here feel slow?" wants SPACE. Picking the framework that matches the question is most of the work; the rest is refusing to use its output for a question it was never built to answer.
Three practical warnings apply to all of them. Every framework that produces a single score has thrown information away to get there, and the discarded information is usually the business context. Every framework that assigns remediation time uses estimates from somewhere other than your team. And every framework becomes dishonest the moment its score becomes a target rather than a description.
You will probably end up with two: one code-level framework for the engineering conversation and one outcome-level framework for the leadership conversation. That is a reasonable place to land, provided you never present one as evidence for a claim the other should be making.
The SQALE Method
Software Quality Assessment based on Lifecycle Expectations. Developed by Jean-Louis Letouzey, SQALE is one of the most widely adopted formal methods for measuring technical debt, and it is the calculation behind a great many dashboards whose owners have never heard the name.
What It Measures
SQALE maps code issues to remediation time. Every detected issue is assigned an estimated fix time based on its category and severity. The total remediation time across all issues is your technical debt principal. That principal is then compared to total development cost to produce the SQALE debt ratio -- a single percentage summarizing the health of the codebase.
The A-to-E Rating
The SQALE rating converts the debt ratio into a letter grade, with A at the healthy end (a ratio under 5%) and E at the critical end (over 50%). The grade is the reason SQALE spreads inside organizations: a letter travels through three layers of management intact, whereas a percentage gets rounded, requoted, and eventually reversed.
What It Is Good For
Defensibility. SQALE has a published specification and a long paper trail, which matters enormously in regulated industries where "our tool said so" is not an acceptable answer. It is also the default debt calculation inside SonarQube, so if you already run SonarQube you are already reporting SQALE numbers whether or not you chose to.
Where It Misleads
SQALE sees only what a static analyser can detect, so architectural, process, and infrastructure debt are invisible to it. The remediation estimates are generic defaults, not your team's actual speed. Worst of all, it is blind to business impact: a critical flaw in payment processing and a cosmetic naming violation can contribute identically to the score.
The Technical Debt Ratio
The most quoted single number in this field, and the most quietly assumption-laden. It expresses remediation cost as a percentage of the cost of building the thing in the first place.
What It Measures
The size of the cleanup relative to the size of the build. If fixing every identified issue would take 200 developer-days against a codebase representing 2,000 developer-days of work, the ratio is 10%. Both terms are estimates, which is the whole story of this metric.
What It Is Good For
Comparing a codebase against itself over time, and comparing modules within one organization that all run the same analyser with the same rule set. As a trend line it is genuinely useful, and it is the easiest debt framing to explain to someone who has never written code.
Where It Misleads
The denominator is usually inferred from lines of code, so deleting dead code can make the ratio worse. The numerator moves whenever anyone edits a rule set. And nobody outside your organization computed theirs the same way, so cross-company comparison of TDR is meaningless however confidently it is presented.
Before you quote a threshold: the familiar "under 5% is healthy" band is the SQALE A-grade boundary, not an independent industry finding. Quote it as what it is - the grade boundary your analyser uses - rather than as evidence about software in general.
ISO 25010: Software Product Quality
The international standard for software product quality. ISO 25010 is a taxonomy rather than a calculation: it produces no score at all. Its value is that it gives every debt item a home in a vocabulary that risk, compliance, and product functions already use.
Functional Suitability
Does the software do what it is supposed to do? Missing features and incorrect behavior map here.
Performance Efficiency
Response times, resource utilization, and capacity. Slow queries and memory leaks map here.
Compatibility
Can the software work with other systems? Integration issues and API incompatibilities map here.
Usability
How easy is it to use? Poor UX, accessibility gaps, and confusing workflows map here.
Reliability
Does it work consistently without failure? Crash rates, error handling gaps, and recovery time map here.
Security
Vulnerabilities, outdated dependencies, weak authentication, and missing encryption map here.
Maintainability
How easy is it to modify? Code complexity, coupling, test coverage, and documentation gaps map here.
Portability
Can it run in different environments? Vendor lock-in, hardcoded configurations, and platform dependencies map here.
What it is good for: framing. "We have 200 analyser issues" means nothing to an executive; "our maintainability and reliability characteristics have both degraded for three quarters" lands, because those words already appear in their risk register. Map every debt item to a characteristic and the reporting problem largely solves itself.
Where it misleads: a taxonomy feels like a measurement without being one. ISO 25010 will not tell you how much debt you have, whether it is growing, or what to fix first, and the eight neat boxes create an illusion of coverage. Classifying every item is also slow work that quietly becomes somebody's whole job.
The Maintainability Index
What it measures: a composite score, reported on a 0 to 100 scale by most implementations, that folds complexity, code volume, and lines of code into one figure per function or file. Visual Studio and several analysers report it out of the box, which is why it turns up in .NET shops more than anywhere else.
What it is good for: triage. Sorting files by the index is a fast, zero-argument way to produce a shortlist of candidates for refactoring when you have no other prioritisation and limited time.
Where it misleads: it is a composite, so a low score never tells you which input caused it, and the underlying formula and colour bands differ between implementations. Check your own analyser's documentation rather than trusting a remembered threshold. It also penalises length, which means a long, boringly explicit, obviously correct function scores worse than a short clever one nobody can read.
SPACE
What it measures: nothing, directly. SPACE is a framework for choosing productivity metrics across five dimensions - satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. Its central instruction is to pick metrics from more than one dimension, so that no single number can be optimised in isolation.
What it is good for: stopping the conversation where somebody proposes measuring developers by commit count. SPACE gives you a principled reason to insist that any activity metric arrives paired with a satisfaction metric and an efficiency metric.
Where it misleads: because it prescribes no specific metrics, two organizations can both claim to use SPACE and share nothing. It also invites metric sprawl - five dimensions become fifteen dashboards. Treat it as a constraint on your selection, not as a shopping list.
Source: Forsgren, Storey, Maddila, Zimmermann, Houck and Butler, "The SPACE of Developer Productivity", ACM Queue vol. 19 no. 1 (2021)
DORA, Considered as a Framework
What it measures: software delivery outcomes, through five metrics grouped into throughput and instability. It is the only framework on this page that measures what happens to your customers rather than what is in your repository. The metrics themselves are defined in full, with collection guidance, on Measuring Tech Debt - deliberately in one place only. Note the count: the famous "four key metrics" are the original 2014 to 2023 set, and DORA's current guidance names five.
What it is good for: connecting technical debt to a business consequence without translation. Nobody needs the concept of cyclomatic complexity explained in order to care that releases got slower and failures got more frequent.
Where it misleads: DORA is a symptom framework, not a diagnosis. It tells you delivery is degrading and says nothing about which module is responsible. It is also the framework most often quoted with numeric grade thresholds that its current publications do not support - a mistake this site made itself, and corrected.
The OMG and CISQ Automated Measures
What it measures: structural quality at the system level, using standardised measures for reliability, security, performance efficiency, and maintainability, plus an automated technical debt measure built on top of them. Unlike file-by-file analysers, these are specified to look across component and language boundaries at whole-system flaws.
What it is good for: large multi-language estates, and any situation where the measurement has to be a recognised standard rather than a vendor's opinion - supplier assessments, acquisitions, and regulated environments.
Where it misleads: the analysis is heavyweight and slow enough that it becomes a quarterly event rather than a feedback loop, and by the time the report lands the code has moved. It is also, in practice, tied to a small number of expensive implementations, so "we follow the standard" often means "we bought that product".
Which Tool Implements Which Framework
Most teams choose a tool and inherit a framework by accident. This table runs the mapping in the other direction, so you can see which opinion you are buying.
| Implementation | Framework it applies | What you inherit with it |
|---|---|---|
| SonarQube | SQALE, with its own cognitive complexity measure | SQALE's remediation-time defaults and the A-to-E grade, applied to whatever rule set is active. Changing the rule set changes your history. |
| Qlty (formerly Code Climate Quality) | Its own maintainability model, plus coverage gating | A per-change verdict rather than a portfolio score. Excellent at preventing new debt, less suited to sizing what you already have. |
| CAST | CISQ and OMG structural quality measures | System-level, cross-language analysis and standards-backed reporting, at enterprise weight and enterprise cadence. |
| NDepend and Visual Studio | Maintainability Index and dependency structure metrics | Depth on .NET assemblies and coupling, and a composite index whose bands are tool-specific. |
| Delivery analytics platforms | DORA | Outcome metrics computed from your pipelines. Check how each vendor defines a deployment and a failure, and whether it has caught up with DORA's current five-metric set, before comparing anything. |
| Your own stack (Prometheus, Grafana, spreadsheets) | Whatever you decide, including the dimensions below | Total control and total responsibility. The right answer when off-the-shelf frameworks cannot express the question you actually have. |
For a feature-by-feature tool comparison and setup instructions see Measuring Tech Debt; for what each one costs see the Tools page.
Four Dimensions the Named Frameworks Miss
Every framework above measures a stock: how much debt exists right now. None of them models the debt the way the metaphor promises - as a balance that accrues, charges interest, and has an origin. These four dimensions are our own, they are cheap to build on top of the counts described on Measuring Tech Debt, and between them they answer questions no off-the-shelf score will.
1. Debt Velocity
Not how much debt you have, but which direction it is moving. Take debt items created in a period and subtract debt items closed in the same period. A positive number means the balance is growing. Plot it as a running total and you have the one chart that answers the question everybody in the room is avoiding.
Modelling notes: counts and effort estimates give different answers, so plot both. Ten cosmetic closures against one architectural addition is a losing quarter that a count-based chart records as a win. Smooth over three sprints, because a single sprint of a team on holiday is not a trend. And expect the created line to rise when you first introduce the label - that is your team finally writing things down, not a sudden collapse in quality.
2. Interest Rate
What existing debt costs you every sprint even when you do nothing about it. If a fifth of each sprint disappears into flaky tests, convoluted code paths, and slow builds, that fifth is your interest payment, and it is charged whether or not anyone approves a remediation budget.
Modelling notes: the honest estimate comes from the unplanned work share, corroborated by the confidence survey. The dishonest one comes from asking people at quarter end to guess what fraction of their time was wasted; that number is always the number they think will get the refactor approved. Interest rate is the single most persuasive dimension in a budget conversation, precisely because it is a cost you are already paying rather than an investment you are requesting.
3. Cohort Analysis
Which vintage of code generates the most defects. Group incidents and bugs by the age of the code that caused them, using version control blame data on the lines that were changed to fix each one. Some quarters produce dramatically more expensive code than others.
Modelling notes: the value is in the explanation, not the chart. When one quarter stands out, go and find out what was true then - a deadline, a reorganisation, a key architect on leave, a new tool adopted without review - because that condition is almost certainly recurring on some cycle. Cohort analysis is the only dimension here that tells you something about your process rather than your code, which makes it the one most likely to be unwelcome.
4. Risk-Weighted Debt
The correction for every framework above that treats all issues as interchangeable. Weight each debt item by likelihood of causing an incident, severity if it does, and blast radius. A naming violation in a rarely-touched utility and a missing validation in the payment path stop scoring the same.
Modelling notes: keep the scale coarse. Three levels per factor is enough, and a finer scale only produces longer arguments about whether something is a 6 or a 7. Multiply the three, sort descending, and you have a remediation backlog that survives contact with a prioritisation meeting. Re-score quarterly - blast radius changes as the system changes, and last year's peripheral service is this year's shared dependency.
Frequently Asked Questions
Start with the simplest framework that answers your actual question. If you need executive communication, use ISO 25010 framing. If you need a number for the size of the cleanup, use SQALE or the Technical Debt Ratio. If you need architecture-level analysis across a large multi-language estate, use the CISQ and OMG measures. If the question is whether delivery is getting better, use DORA. Most teams are best served by starting with SonarQube, which gives them SQALE whether they intended it or not, and adding an outcome framework once the code-level one is running.
Usually two, and rarely more. One code-level framework gives engineers something specific to act on; one outcome-level framework gives leadership something they already know how to value. The failure mode is not having two, it is letting one answer the other's questions - quoting a debt ratio as evidence that delivery improved, or quoting DORA as evidence that a particular module needs rewriting. Neither claim is supported by the framework making it. Write down, once, which framework owns which question, and hold that line in every review.
SQALE is a calculation and ISO 25010 is a vocabulary. SQALE takes analyser findings, assigns each one a remediation time, totals it into a principal, and divides by development cost to produce a ratio and an A-to-E grade. ISO 25010 produces no number at all; it defines eight quality characteristics that any given debt item can be filed under. They are complementary rather than competing: SQALE tells you the cleanup is roughly 8% of the build cost, and ISO 25010 tells you that most of it sits under maintainability and security rather than performance. Teams that use both typically report the grade to engineering and the characteristic breakdown to everyone else.
Not directly. DORA measures delivery outcomes - grouped as throughput and instability - and technical debt is one of several things that can degrade them. That indirection is a feature when you are talking to executives, because the metrics describe consequences they already care about, and a limitation when you are trying to decide what to refactor, because DORA cannot point at a module. Use it as your outcome framework alongside a code-level one, and be careful with two things. First, grade language: the numeric performance-cluster thresholds widely attributed to DORA are not supported by its current publications. Second, the count: DORA's current guidance names five delivery metrics, and the familiar "four key metrics" are the original set from its earlier research. Both the metrics and the collection guidance live on Measuring Tech Debt.
Pick a Framework, Then Go Measure
Choosing the framework is the short part. Instrumenting it, and putting the result somewhere people will look, is the work.