Jean-Louis, static code analysis has been around for a long time, what made you start working on this?
I started looking for a way to measure and report source code quality about 10 years ago. At that time, I wasn’t happy with the measurement and reporting methods embedded within the static analysis tools. The results were not presented in a way that made it easy to get an overview and find out where to start improving. So I decided to study the topic and see if I could find a more rigorous way to analyze the results.
My initial findings were:
- First that the quality of the diagnostic was highly depending on the way the basic measurement and findings are aggregated.
- Second, that all quality characteristics are not equals, Testability is the mother, the foundation of all quality characteristics. This should be raised, highlighted within a code quality report.
Then, I started researches, experiments, publications, validation projects …. It took me about 3 years to publish the first public version of the method.
So what did you develop?
Based on these ideas I developed the SQALE method where the quality attributes are aggregated (picture 1), as well as divided into risk levels (picture 2) all based on remediation cost (effort to fix the problems).
Picture 1- Technical Debt Pyramid
Picture 2- SQALE Risk Levels
This way of looking at code metrics, i.e. remediation cost, risk level and what quality attribute they impact is very powerful. It helps the organization in selecting metrics, analyzing the results and prioritizing code improvements.
We now see that the SQALE method is implemented and promoted in several leading code metrics tools, e.g. SonarQube, Squoring, Mia Software….
There is a blog on the SQALE homepage giving a more in depth description of SQALE pyramid and it usage that we recommend.
Code metrics is now also become a very important part of the Agile methodology through the concept of technical debt, is that the same as SQALE? And will this lead to more use?
The technical debt concept was a complete paradigm shift. This is a major step in code quality measurement. Because technical debt is aggregated by summation, it provides more reliable diagnostic (I mean, less false positive) and much more understandable and actionable results. In addition, the measure itself (the technical debt estimated in days or money) is understandable by all the IT team, from developers to CIO. This increases the acceptance and usage of static analysis.
SQALE is 100% aligned with the technical debt concept, i.e. technical debt is remediation cost.
SQALE usage is also growing very fast because it goes beyond the simple measurement of the technical debt. The method provides support for analyzing this debt and make decisions. It also provides and supports remediation strategies, as is illustrated in the two earlier pictures.
SQALE contains some specific features for providing these capabilities.
- One of them is to distribute the issues and associated debt upon the expected characteristics like reliability or maintainability.
- Another one is to quantify the issues upon 2 aspects, 2 perspectives:
- The Remediation Cost (which is the principal of the debt)
- The Non Remediation Cost (which is the interest of the debt, the additional cost incurred by delivering the code with the issue, in other words, keeping the debt)
- This extra information provides deep insight on the nature of the debt. Finally, dedicated indicators provide guidance for repaying the debt depending on your objectives and context (mainly the available budget)
Another interesting usage of the static code analysis was in the Barr analysis of the Toyota Unintended Acceleration court case in the US. What is your comments on this?
As static code analysis is becoming more “state of the practice” compared to “state of the art” it will be expected that all systems, in particular safety critical systems are compliant to them.
I think that because software is more and more around us, software quality and lack of quality will become more and more visible. As a consequence of “software everywhere”, the demand for high quality software will grow.
The technical debt concept contributes to quality assessment but also helps on a day to day basis developers to build better software.
The ultimate goal for static analysis is to help developers do it right the first time and I think that continuous code inspection/metrics will become standard practices.
In the SQALE method you are using quite traditional code metrics, but there is some recent development in this area that I find interesting, e.g. CISQ, where you go deeper into the semantic of the code. What is your view on this development?
All initiatives that contribute to the definition of what is “right code” will help to build better software. SQALE is independent of the actual code metrics, it can work with any metrics that you can extract from the code, so the more advanced the metrics become the better the SQALE will become.
I am part of the CISQ and I have leaded one of the technical workgroup and have contributed to the elaboration of this document.
I am also part of a community , which assemble people from industry and research. That group is fully dedicated to Technical debt. We organize regular workshops with the goal to exchange, publish on the topic. The next step may be to establish common definitions, common understanding of the concept and then to provide guidance on the topic.
It is important to be able to identify and quantify Technical debt, but the most important is to be able to “Manage” technical debt. That means at least to answer questions like:
Which part of my debt is critical? Which application should get priority? In this application, where do I start for repaying technical debt?
Good Technical debt Management will save a lot of money. There is a long way before answering and mastering all the questions around Technical debt but SQALE try to contribute on this way.
Thanks a lot Jean-Louis for your insight into static code analysis and technical debt.
Addalot