Interview with Jean-Louis LETOUZEY on Technical Debt and SQALE

One week after our discussion with Ward Cunningham on technical debt, we thought it would be of interest for our readers to get more information on how to measure it. Even if the debt metaphor should be sufficient in itself in many cases, quantitative and tangible data may provide “shareholders” with precious indicators for their “investment decisions”. So, let’s have a talk with Jean-Louis LETOUZEY, author of the SQALE method and expert consultant at Inspearit. For having implemented myself in a previous life, SQALE is by far one of the simplest and most powerful method to quantify the cost of code defects’ remediation.

You are the author of the SQALE method, can you tell us about the origin of the method?

The method answers to a generic need identified by inspearit consultants; Users of static analysis tools were looking for source code quality dashboards that would be objective, precise and representing the perceived quality. These findings served as guidelines for developing the method, for defining its principles and its concepts. In practice, it leads to identifying and managing the technical debt present in the source code of an application.

Another important requirement was for a generic method which would be analysis tool independent. That is the reason why we have decided to define standardized visual indicators (e.g. the “SQALE Pyramid”). These indicators are defined as a visual communication and reporting language which can be used whatever tool has been selected to analyze the code.

As of today, how is the method widespread?

Since August 2010, when inspearit decided to publish the method under an open source license, it has received growing recognition. More and more experts like Israel Gat recommend the method. Hundreds of organizations use it on a daily basis and feedbacks show that users are very satisfied by the way the method helps them to make decisions about refactoring and priorities. The method is spread by users recommending it to their colleagues.

There are currently four analysis tools which implement the method and I am in contact with other tool editors. That said, in order to support the method, tools shall be able to control a wide spectrum of requirements (architecture, structure, implementation, naming, presentation…), which is not an ordinary feature. Some tools are too specialized, for instance on security flaw detection, and cannot support directly the method.

You recently participated to the 3rd international workshop on managing technical debt, what is your feedback?

This was a very interesting meeting which allowed me to meet and exchange with important contributors on the topic of technical debt. Presentations were globally interesting and innovative. The two main topics that stand out for me are:

• For the majority of attendees, it is important not to limit the concept to the source code related debt. The definition of technical debt should remain very large, allowing including all kinds of bad practices (like using old libraries or framework, non-optimized processes, etc.).
• The metaphor is very powerful and useful. There is even more interest to use the concept in conjunction with other financial concepts like Business Value and Net Present Value to analyze and manage the portfolio of current applications and new projects.

Did you read the Ward Cunningham interview published on our blog and what is your feeling?

Yes, of course, I read it. Ward Cunningham is the father of the metaphor and everything he says on the topic is of prime importance. What I will remind is that he makes it clear that, for him, the concept is very large and should not be limited by a too precise definition. Technical debt is defined by its impact and not by another way. If there is a negative impact, there is a debt.

I think that if you want to reap all the benefits of the metaphor, you need to monetize the debt (managers like to manipulate numbers in Excel sheets, not text). That is what the SQALE users are doing. By doing that, you are obliged to specify the exact perimeter of the technical debt you are monetizing and the detailed way you estimate it. Then, what is important is to make people aware of the limitations of your approach, to make sure that there is no ambiguity about the numbers you provide and use.