The SQALE Pyramid: A powerful indicator

Meaningful insights into your Technical Debt

The SQALE Pyramid is certainly the most useful indicator of the SQALE method. It gives a lot of information on the nature of the technical debt and thus helps to make decisions. I will try to show how it helps to answer questions that often arise once you have quantified the technical debt of your application.

Imagine that you have analyzed the code of your application or your project and the total technical debt estimated with SQALE is 50.7 days.

We will run through some questions that could be asked and will see how the SQALE pyramid helps to respond.

Is it a short-term or long-term debt?

The SQALE pyramid shows the distribution of the technical debt according to the chronology of expectations during the life cycle of a code file. The short term parts of the technical debt are the lower layers of the pyramid (Testability and Reliability) and the parts that will have an impact in the longer term (Maintainability, Portability, Reusability) are the upper layers of the pyramid.
The following example (as reported by the SonarQube tool) shows the distribution of a debt of 50.7 days: there are 13.8 (4.0 + 9.8) days with rather short-term and 30 days of a long-term nature. This is long term as the impact of this debt will only be perceived when transferring the maintenance of the code to another team.

How critical is my technical debt?

All the issues found in the code are not identical. Some may have high negative impact on the business, such as security or reliability related issues. Following the Technical Debt metaphor, this is the part of the debt with the highest interest. In this category, you will find issues such as logic errors or mismanagement of exceptions.

Other issues are less critical because their presence won’t directly affect the business.

In the example below, the amount of critical debt (that means related to the « Reliability » and “Security ” layers of the pyramid) is 10.4 days, or 20% of total.

How much effort should I spend to make my code more reliable?

Firstly, if you want your code to be reliable, you should also include into your Quality Model a requirement related to test code coverage. This will ensure the efficiency of your test activities (either unit test, integration and/or functional tests). This requirement (e.g. 80 % lines coverage rate for all files) should be integrated into your SQALE Quality Model under the Reliability characteristic.

As explained in various articles available on this site, in order to ensure reliability of the code, you should at least solve all the issues related to testability and reliability. So the effort to spend is the sum of the Testability and Reliability debt (which in the SQALE Method is called the SQALE Consolidated Reliability Index -SCRI). In our example it is 13.8 days.

This effort is necessary to improve the reliability of the application, but of course, this is not sufficient. The reliability of your application depends also on other efforts performed on additional activities like peer reviews, beta testing, etc.

How much effort should I spend to make my code more maintainable? (in other words, to reduce the required annual charge to fix bugs and implement Change Requests)

The same logic applies. You must look at the SQALE Consolidated Maintenance Index (SCMI). To reduce future maintenance costs, you should resolve issues related to testability, reliability, changeability, security, performance and maintainability. In this example, you will need to spend a 50.7 days’ workload.

Where do I start to repay the technical debt of my code?

They are multiple strategies for setting refactoring priorities.

The most relevant one depends mainly on your context and especially on the budget you can allocate to this activity.

Let’s illustrate 2 cases:

1 – You are far from the delivery date, and so you can allocate a workload representing a large percentage of your total technical debt (at least 60%)

In this case, you need to improve the quality of code by first making it testable. That is to say, solve such issues as too complex methods, duplicated code, etc. Then you pay back the debt associated to the next upper layer of the SQALE pyramid, which is the reliability, and so on.

2 – You have very little time. You can’t repay the debt related to testability because it’s structural and so time consuming. So, you will deliver your application with remaining debt, thus it would be wise to reduce the criticality of this debt. You will focus your efforts to correct the critical issues, the ones with the highest potential business impact. These are the issues related to reliability. In this case you will need 9.8 days.

It should be noted that this last strategy to improve the code is not optimal, because maybe you’ll fix potential bugs in pieces of code that should be refactored for testability reasons. This time may then be lost. We can say that this is the « quick and dirty » way to manage Technical Debt.


As shown, this pyramid helps to answer many questions related to source code quality. To summarize, the SQALE pyramid helps you to analyze and understand your technical debt on three aspects:

  • · Maturity of the debt
  • · Severity
  • · Remediation order

Instead of communicating just the total amount of Technical Debt, it is more useful to report its distribution in the form of a SQALE Pyramid. This should be part of good Project Management Dashboards.

P.S. The Pyramid helps to answer many other questions, I covered another one: “How agile is your code?” in a previous post here.