SQALE models – more than just tiny cities*

This week I want to talk about SQALE – which is commonly pronounced “scale.”

Before I joined SonarSource, I tried many times to understand what SQALE was about, but I just couldn’t get a grip on it. Recently, I sat down with SonarSource Senior Consultant David Racodon, who walked me through it, and made it seem simple. Since version 4.0 brought the fundamentals of SQALE into SonarQube core for everyone to use, I think it’s important to share what I learned in case anyone else is puzzled too.

Why port basic SQALE into SonarQube core

But first I want to address the movement of the SQALE basics into SonarQube core. You may be aware that there’s a commercial SQALE plugin. If so, it would be fair to wonder why SonarSource is now giving away part of what it had been charging for. Is this the free sample that’s supposed to entice you into buying the plugin? In a word, no. (Although it won’t hurt the feelings of anyone at SonarSource if you do buy the plugin). I asked Product Manager Freddy Mallet about the change. Here’s what he said:

Because the main goal of the SonarQube platform is to manage the “Technical Debt” but the amount of this technical debt was not available out-the-box. It was up to the users to use the open source “Technical Debt”, “SIGMM”, “Quality Index” plugins, or the commercial “SQALE” plugin.

So by embedding SQALE into the SonarQube platform, we’ve solved three issues :

  1. No need to plug an external plugin to get what SonarQube is supposed to provide out-the-box
  2. Standardization of the “Technical Debt” model -> we do believe that SQALE is currently the best one
  3. Ability to improve the integration of the SQALE model into SonarQube (tracking of added remediation cost in 4.1, ability to override the remediation cost on each issue, …)

So that was the motivation. Now on to the meat: what is SQALE?

What is SQALE?

I’ll start with the basics: SQALE is about assessing and managing technical debt. It’s a methodology that was developed by inspearit and then open sourced. When I tried to read the SQALE documentation, I saw that it is about organising the non-functional requirements that relate to the code’s quality. And I always wondered where I was supposed to come up with those requirements. David helped me understand that the non-functional requirements are the rules in your profile. Doh!

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 rules in SonarQube repository. 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.

How SQALE works

If you’re familiar with the old Technical Debt plugin you know that it also measured technical debt in days. I had it installed at my day job, but I never did much with it because the calculations seemed so crude to me – there was a set of types of problems, and you provided an estimate of the time to fix an issue of each type. But the categories always seemed too broad to me to produce good results.

SQALE answers that complaint – it provides time estimation at the rule level. If you’ve got the SQALE plugin on board then you get to tweak those estimates. (In doing so, you’re editing the SQALE Analysis Model – the remediation cost of each rule.) If you’re just being introduced to SQALE though the 4.0 version, then you’ll have to be content with the default value for each rule.

With your first analysis after your upgrade to 4.0 you’ll see the technical debt for each issue added to the issue block:

Add up the technical debt for all the issues, and you get the application’s total technical debt, which now shows up in the issues widget:

Prioritizing the fix

So now you know how long it will take to fix the application, but how do you prioritize the work? There’s a new widget for that (well, new to SonarQube platform – it was available in the SQALE plugin for quite a while before the SonarQube 4.0 release). It’s called the technical debt pyramid, and it looks like no pyramid you’ve ever seen before:

Looking at this widget and seeing it called a pyramid is one of the things that always confused me before. Fortunately, David explained to me that this is a figurative pyramid.

The way to read this widget 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.

What’s left: highlights of the SQALE plugin

That covers what has been added to SonarQube core. While I’m on the subject, we’ll take a peek at what the SQALE plugin offers – I’ve always been impressed by how pretty and colorful the SQALE dashboard is.

If you’ve got the SQALE plugin, there are a number of other widgets / ways to slice your technical debt. The SQALE pyramid by severity will seem the most familiar, combining the normal Issues widget with the SQALE pyramid presentation:

This one does look more like a pyramid because the broadest bar in the graph will always be on the bottom, with the most important (and smallest) bar on top.

If you’re on a search and destroy mission for technical debt, you might prefer a focus on files. There’s a hotspot widget for that: Highest SQALE remediation costs:

The SQALE History widget will also be somewhat familiar; it resembles the timeline widget. Here they are, side by side:

As you see, the SQALE History graph shows your technical debt by characteristic across time. You’ll notice the two widgets are quite similar in concept and presentation, with the same event triangles and mouseover behavior.

One thing you don’t get with the SQALE History graph is a clickthrough, but this next widget should satisfy that in spades. The SQALE Sunburst widget shows the current state of your technical debt broken down not just by characteristic, but also potentially by subcharacteristic and rule. I say potentially because it’s configurable. Here are all three variations:

Working from the inside out, the graph levels are: characteristic, subcharacteristic, and rule. Clicking on a rule takes you to a drilldown.

Under the covers

I’ve focused mainly on what’s visible here. I should also mention that the organization behind these graphs is configurable if you’ve got the SQALE plugin. Testability is at the bottom of the Technical Debt pyramid as the most fundamental characteristic, but that’s only the default. If you think some other characteristic is more important, then you can move its position in the graphs. In doing so, you’re editing the SQALE Quality Model – the list and order of the characteristics.

Similarly, the subcharacteristics that make up a characteristic, and the rules in a subcharacteristic are also configurable. I mentioned earlier that if you edit the remediation cost / time estimate of a rule, you’re editing the SQALE Analysis Model. Editing the subcharacteristic of a rule also qualifies as editing the SQALE Analysis Model.

It’s not terribly important that you know or remember which edits are part of which model, but without explanation all these different models – the SQALE Model, the Quality Model, and the Analysis Model – can be confusing. At least, they were for me.

The view from on high

The last thing to show you are the macro widgets. They look not at your technical debt breakdown, but at the higher level:

The SQALE Overview widget is at the top. It gives you… well, an overview. Most notably, it gives your application’s letter grade. It’s based on an estimate of the effort that has gone into the development of the application versus its outstanding technical debt remediation effort. If your application doesn’t have an A grade, then this widget also tells you what effort will be required to reach that level.

Next is the SQALE Rating File Distribution. Just as your application gets a grade, so too do the files in it, and this widget shows the breakdown. Note that the grade scale is shown in the lower-right corner. There is no ‘F’, so perhaps it’s not correct to refer to this as a grade. In fact, it’s officially a “rating”, not a “grade”, but when I see a page stamped at the top with an ‘A’ it’s hard not to think in terms of grades. Perhaps I spent too long in school.

This post has grown long enough that I can’t in good conscience claim to have put SQALE in a nutshell, but hopefully I’ve provided a helpful overview. If you want more detail on the SQALE methodology, head over to SQALE.org. For more on the SQALE plugin, check out the plugin site.

*It is only the humorless who think that puns are the lowest form of humor.

© 2008-2013, SonarSource S.A, Switzerland. All content is copyright protected. SONARQUBE and SONARSOURCE are
trademarks of SonarSource SA. All other trademarks and copyrights are the property of their respective owners. All rights are expressly reserved.