Skip to end of metadata
Go to start of metadata

Table of Contents


The computation of technical debt is based on the SQALE (Software Quality Assessment based on Lifecycle Expectations) methodology.

SQALE is a methodology that was developed by inspearit and then open sourced. If you read the documentation at, you'll see that it's about "organising the non-functional requirements that relate to the code’s quality." In the SonarQube implementation of the SQALE method, those non-functional requirements are the coding rules in your quality profile 

Yes, the SonarQube implementation of SQALE is based solely on rules and issues. That means that if you want to manage all your technical debt with SQALE, you'll first need to enable the rules in the Common SonarQube repository that flag:

  • Duplicated blocks
  • Failed unit tests
  • Insufficient branch coverage by unit tests
  • Insufficient comment density
  • Insufficient line coverage by unit tests
  • Skipped unit tests

Those rules are in the Common SonarQube repository because they're common to all languages. Once you've got them enabled, you can track every quality flaw as an issue, and you're ready to track technical debt, which the SQALE method measures in days. 

Computation of technical debt

On the default dashboard, you can see the overall technical debt of your project thanks to the "Issues and Technical Debt" widget:

Those day measurements are made by summing the technical debt accrued for each issue, which you can see in the issue block when opening a source file:

The technical debt for each issue is set at the rule level. If you've got the commercial SQALE plugin, you can adjust the estimate for each rule (in doing so, you’re editing the SQALE Analysis Model – the remediation cost of each rule). But those estimates were made by seasoned professionals, so you probably won't need to.

Where to start paying the technical debt?

So now you know how long it will take to fix the application, but how do you prioritize the work? There's a widget for that. It’s called the technical debt pyramid, and it looks like no pyramid you’ve ever seen before:

Don't be confused by the fact that this doesn't look like something from ancient Egypt; this is a figurative pyramid. The way to read it is from the bottom up. The bottom row will always have the smallest bar in the bar graph, but it has the biggest import – because it’s foundational. The rows in this widget each represent a “characteristic” and each characteristic builds on the ones below it. Testability is at the bottom because it’s most important: first you make sure your app is testable, then you make sure it’s reliable, then changeable, and efficient, and so on.

The bars in the graph show remediation time per characteristic. The light blue portion shows the time to clean up this characteristic, and the dark blue portion shows cumulative time, working from the bottom up. As usual, each portion of the widget clicks through to a drilldown to let you see exactly where the technical debt for a characteristic is.

Comparing projects with the Technical Debt Ratio and the SQALE Rating

OK, this is very interesting to see that the team must pay 95 days to fix the application. But how does it compare to this other project that has about the same amount of technical debt but that is far smaller?

This is where the Technical Debt Ratio metric is interesting. This metric gives the ratio between the actual technical debt and the effort it would take to rewrite the whole source code from scratch. The latter is estimated based on either the number of lines of code or the overall complexity, which means that the value for this metric depends on the size of the project. And given the value of this ratio, the project gets a SQALE rating going from A (best grade) to E (worst grade).

This is displayed in the "Technical Debt Synopsis" widget:

These 2 metrics are computed at the file level (and thus visible in the Component Viewer) and aggregated up to the project level.



Let's consider 2 projects with the same amount of technical debt:

  • Project Foo: 95 days and 80 000 lines of code
  • Project Bar: 95 days and 7 000 lines of code

The technical debt ratio formula is: "technical_debt" / "estimated_development_cost". And by default (this can be changed in the settings of SonarQube), the "estimated_development_cost" is computed as "LOC x 30 minutes". This gives (technical debt must be converted to minutes, and the number of hours in a day can also be customised):

  • Project Foo: (95 x 8 x 60) / (80 000 x 30) = 1,9%
  • Project Bar: (95 x 8 x 60) / (13 000 x 30) = 21,7%

Here, this is obvious that project Foo is in a better shape than project Bar.

From there, and using the default rating grid (this too can be customised), project Foo gets a "A" grade whereas project Bar get a "C".

Going Further

The SonarSource SQALE plugin extends the technical debt feature embedded in SonarQube. Among other features, it allows to tune the SQALE model (adjust the remediation estimates for each rule, set the list and order of characteristics, change which characteristic a rule falls under, and more), provides additional widgets, etc.


  • No labels