Engineering Practitioner Brief / 18 May 2026
The SQALE Method: Measuring Technical Debt in Hours and Dollars
SQALE is the oldest serious methodology for translating code-quality findings into engineer-hours and dollars. It is the basis for SonarQube's technical-debt metrics and the conceptual root of most static-analysis tools that report a dollar figure. This page explains how SQALE actually works, why its numbers look authoritative but should be treated as estimates, and how to use it without being misled.
Origin and Standard
SQALE was developed by Jean-Louis Letouzey at INSPEARIT (now part of inspearit) and published in 2009 as an open methodology. The full name is Software Quality Assessment based on Lifecycle Expectations. The methodology is documented in the SQALE method definition (a free PDF) and is implemented by several static-analysis tools, of which SonarQube is the most widely deployed.
SQALE distinguishes itself from earlier code-quality measures (cyclomatic complexity, the various maintainability indexes) by being explicit about what it measures and how the measurement maps to actionable work. Where a maintainability index returns a number between 0 and 100 without a defined unit, SQALE returns a remediation cost expressed in time. The unit is hours; the conversion to dollars is straightforward given an engineer-rate input.
The Two Core Calculations
Remediation Cost
For each rule in the SQALE Quality Model (or in a tool that implements it), an analyst defines the time it would take to fix a single violation of that rule. The SonarQube defaults include several hundred rules with assigned remediation costs. Sample costs from the SonarQube default rule pack:
| Rule | SonarQube Default Cost |
|---|---|
| Cognitive Complexity of method is above limit | 10 min per excess unit |
| Method has too many parameters | 20 min |
| Method is too long | 30 min |
| Duplicate block of code | 20 min per duplicate |
| Public method should have a Javadoc | 10 min |
| String literal duplicated | 2 min |
| Class should be refactored to extract responsibilities | 1 hour |
The total remediation cost for a codebase is the sum of (rule violations x rule cost) across all violations. For a typical 100K-line Java application, SonarQube might report a remediation cost in the range of 200 to 2,000 hours, depending on rule strictness and codebase quality.
Development Cost (the denominator)
The SQALE rating is the ratio of remediation cost to development cost. Development cost is estimated as (lines of code x cost per line). The SonarQube default is 30 minutes per line, but this varies by language and is configurable.
For a 100K-line codebase, development cost at 30 minutes per line is 50,000 hours. If remediation cost is 1,000 hours, the SQALE ratio is 2 percent. The corresponding SQALE rating is A.
The choice of cost-per-line is the most-tweaked dial in SQALE practice. A higher cost-per-line inflates the denominator and improves the rating without changing the codebase. Teams that compare ratings across organizations or against external benchmarks should always check what cost-per-line assumption is being applied.
The Rating Bands
SonarQube's default rating bands for the SQALE ratio:
| Rating | SQALE Ratio | Interpretation |
|---|---|---|
| A | 0 to 5% | Healthy, low remediation effort |
| B | 6 to 10% | Manageable, attention warranted |
| C | 11 to 20% | Material debt, investment justified |
| D | 21 to 50% | Heavy debt, dedicated remediation work needed |
| E | over 50% | Critical debt, structural intervention needed |
The bands are intuitive for non-engineers and convenient for trend reporting. They are also coarse; a project at 9 percent is materially closer to one at 11 percent than the band boundary suggests. For internal-decision purposes the raw ratio is more useful than the letter.
The Quality Model
SQALE organizes its rules into a hierarchical Quality Model. The top-level characteristics correspond to ISO/IEC 9126 quality attributes: Testability, Reliability, Changeability, Efficiency, Security, Maintainability, Portability, Reusability. Each characteristic has sub-characteristics, and each sub-characteristic contains a set of rules. The model is implementation-neutral; different tools assign rules to characteristics differently.
The hierarchy lets organizations report not just "total debt is X hours" but "the debt is concentrated in Testability (60 percent) and Changeability (25 percent), with smaller contributions from Reliability and Security." The decomposition is useful for prioritising investment.
Where SQALE Falls Short
Three structural limitations are worth knowing about before adopting SQALE for high-stakes decisions.
The remediation costs are estimates, not measurements.The SonarQube default of 10 minutes per excess unit of cognitive complexity is plausible but not based on time-tracked data. The actual fix time in any specific case depends on test coverage, refactor scope, code-review latency, and many other factors. The aggregate number is therefore directionally right but precisely wrong.
SQALE measures code-level rule violations and misses architecture.A codebase where every method is short, every class has a Javadoc, and every test exists can still have a fundamentally broken architecture (wrong service boundaries, missing abstractions, coupling between layers that should not exist). SQALE will rate this codebase A while the structural debt continues to slow delivery. See monolith decomposition cost for the kind of debt that SQALE does not see.
The denominator is gameable. Choosing a higher cost-per-line in the configuration improves the rating without improving the codebase. Organizations that compete on SQALE rating between teams sometimes find the numbers improving for reasons that have nothing to do with codebase health.
How to Use SQALE Without Being Misled
Four practical recommendations from teams that have used SQALE-based metrics for years:
- Track the SQALE ratio over time within a single codebase with a fixed configuration. The trend is more reliable than the absolute number.
- Use SQALE to identify the top 5 to 10 contributing rules in your codebase. Fix those rules. The list is more actionable than the aggregate number.
- Pair SQALE with separate measures of architectural debt (manual review, dependency-graph analysis, DORA metrics). Do not rely on SQALE alone for the architectural question.
- If you must report a dollar figure, multiply remediation hours by your actual fully-loaded engineer rate, not the tool's default. Show the calculation explicitly.
Related Reading
- SonarQube technical debt ratio explained
- Code Climate maintainability score
- CAST Highlight technical debt index
- Technical debt statistics 2026
- Types of technical debt
Frequently Asked Questions
What is SQALE?
SQALE stands for Software Quality Assessment based on Lifecycle Expectations. It is a methodology developed by Jean-Louis Letouzey, first published in 2009, for quantifying technical debt as remediation effort. SQALE answers two questions: how much engineer-time would it take to bring this codebase to a defined quality baseline, and how does that effort compare to the development cost already spent.
How does SQALE calculate remediation cost?
Each code-quality rule (drawn from the SQALE Quality Model) has a remediation cost assigned to it, expressed in time. For example, a missing test for a public method might cost 30 minutes; an overly-complex method might cost 1 hour; an architecturally-misplaced class might cost 8 hours. The total remediation cost is the sum of remediation costs across all rule violations in the codebase.
What is the SQALE Rating?
A letter grade (A through E) derived from the ratio of remediation cost to development cost. SonarQube's default scale: A is under 5 percent, B is 6 to 10 percent, C is 11 to 20 percent, D is 21 to 50 percent, E is over 50 percent. The grade is intuitive for non-engineers but the underlying ratio is the more useful number for engineering decisions.
How does SonarQube implement SQALE?
SonarQube has implemented SQALE since around 2013 as the basis for its 'Technical Debt' and 'Maintainability Rating' metrics. The rule remediation costs are configurable per organization. SonarQube also adds the 'Reliability' and 'Security' ratings (based on bug and vulnerability detection) that complement the SQALE-based maintainability rating.
What are SQALE's limitations?
Three. First, the remediation costs are estimates, not measurements; the same rule violation can take very different time to fix in different contexts. Second, SQALE counts code-level rule violations but misses architectural debt (a clean codebase with a broken architecture can score A). Third, the SQALE rating depends on the development-cost denominator, which is itself estimated and can be tuned to produce a desired grade.
Is SQALE worth using?
Yes as one input among several, no as the sole measure. SQALE is useful for tracking codebase trend (is the debt growing or shrinking?), for comparing modules within an organization (which module needs investment?), and for triggering policy gates (block merges that worsen the SQALE rating). It is not useful as the sole basis for an external benchmark or for strategic architectural decisions.