I would like to clarify and explain what makes this concept different and powerful.

1. What is important is to stop characterizing non-conformities (or whatever you call them, violations, bad practices…) on a 1 to 5 or 1 to 10 range. This practice, which comes from classic risk analysis methods, is not representative of the issue. In real life, impacts of problems are on an unlimited range. The impact may be 1 for a small problem and 100,000 or more for a “very big”one.
2. If you characterize your non-conformities on a 1 to 5 or 1 to 10 range, you use an ordinal scale. This bans any aggregation by summation. SQALE, through the concept of Non-Remediation Cost, use a ratio scale, which provides a realistic and representative aggregation by summation, as we commonly do for Remediation Cost and Technical Debt.

In many cases, it will be very difficult to estimate the Non-Remediation costs in a tangible unit as hours or $. I recommend using a symbolic unit. The key point is to estimate and represent the real relative impact to the business of the different types of non-conformities.

From now, with the ability to analyze the non-conformities from a Technical and a Business perspective, you almost have the necessary information to optimize and manage your Technical Debt.

The current version of the SQALE Method Definition Document supports and helps to manage the Technical Debt of an application/project. The new version of the method (which will be publicly released soon) will continue to use the debt metaphor and help you to manage two concepts:
•    The Technical Debt, which is now well understood. (If needed, you will find more detail here. If you want to know everything, there is the complete reference book from Chris Sterling here). I remind you that the SQALE Quality Index is an objective and precise estimation of the Technical Debt accumulated within a piece of source code.
•    The Non-Remediation Cost, a new concept, which I want to introduce here.

I will introduce the Non-Remediation Cost concept with a simple analogy.
Let’s imagine that you need a new office building. So, you write a specifications document, which contains your functional requirements and also your quality requirements. Here are two examples of such quality related requirements:
•    For security reasons, you require video cameras at strategic locations of each floor
•    For thermal insulation reasons (or whatever reason), you require that all windows have double glazing.

If during the building phase, you or the building team discovers some non-conformity regarding these requirements, the building company will evaluate the remediation cost of the issues in order to understand their relative importance and their impact on the project’s planning and budget. The useful information during all the building phase and the concept which will be used by the development team is the “Technical Debt”. The Technical Debt is a relevant measure to manage non-conformities during the building phase.

Let’s suppose that very close to the delivery date, you visit the building for control and you discover 5 single glazing windows and 2 missing video cameras. As there is not enough time to fix the 7 issues, you will be obliged to find a compromise. Which information will help you to make the smartest decision, the best compromise?
In fact, you will look after the cost of leaving the non-conformities and you will try to answer the following question:
What will be the impact of leaving simple glass window against missing cameras in some places of the building?
At that moment, what counts is the business perspective. That means the real or potential damages resulting of the non-conformities. The monetization of the damages can be summarized as a cost which is transferred to the client and/or the owner, that’s what is called the “Non-remediation Cost” (you also may call it the “Business Debt”). The Non-Remediation Cost of each issue will be compared to its Technical Debt in order to set remediation priorities.

To summarize the metaphor:
The cost of fixing a non-conforming window is a Technical Debt, that’s the cost that the building team will have to pay to fulfill its commitment.
The extra heating cost (and the total monetization of all other damages) resulting of keeping a non-conforming window is a “Non-Remediation Cost” transferred to the owner – the business, and resulting of the delivery of a non-conformity.

Non-Remediation Cost applied to source code quality

Now, if we apply both concepts to source code:
First I remind you that within SQALE, source code quality is simply compliance to source code related requirements.
The Technical Debt represents the cumulated negative impact of the non-conformities on the real development cost of the project. The interest of that debt is a decrease of development productivity.
Technical Debt will impact the figures of the Development Plan.

The Non-Remediation Cost represents the cumulated negative impact of the same non-conformities on the real business value of the project. The interest of that debt is a decrease of the project’s ROI. Non-Remediation Cost will impact the figures of the Business Plan.

Both concepts and the metaphor apply to all types of development methods (agile or not). Both concepts are the monetization of stated non-conformities.
The Technical Debt represents the technical perspective of the findings; the Non-Remediation Cost (or Business Debt) represents the business perspective of the same findings.

How to use both perspectives

When you just want to monitor source code quality, you just want to monitor “how far” you are from your quality requirements. Then you will mainly monitor and analyze your Technical Debt.
If you want to optimize your quality versus your effort, then you will use both concepts, both information, the Remediation Cost and the Non-Remediation Cost. You will spend your limited remediation budget on remediations with the best ROI. That means, you will try to decrease your transferred costs (Non-Remediation Cost) while spending the less remediation effort.

The following graph illustrates the usage of both concepts.

I think the new concept just provides the means to manage the remediation’s priority as you manage the feature’s priority:
Priorities regarding the implementation of functionalities are established by taking into account associated development costs and business values.
In analogy, the remediation’s priority of non-conformities is established by taking into account associated Technical Debt and Non-Remediation Cost. The analogy is illustrated below:

In conclusion, the two concepts provide two different perspectives, two different pieces of information for analyzing and managing the non-conformities of your code. The Technical Debt is a first level indicator for day to day monitoring. The Non-Remediation Cost is a second level indicator for performing optimization, compromise and setting priorities.
The new version of the SQALE Method Definition Document (coming next month)  will support you with relevant indices and indicators.

Context over Content

“Context over Content” is my mantra in just about every consulting engagement I carry out these days. You will literally hear me tell my clients something like “Values, principles and practices are, of course, extremely important. However, as far as this engagement is concerned the only thing that really matter is how we will jointly apply them in your specific context – your needs, your resources, your predicaments, and your constraints.” In the domain of software quality evaluation, I find SQALE – Software Quality Assessment based on Life Cycle Expectations – a great tool for implementing my mantra. It interprets source code analysis in terms of what really matters in the specific client environment. In so doing, it transforms an overwhelming set of measurement data to actionable insights which are meaningful at multiple levels of the firm.”

Israel Gat, January 2012

See the complete agenda of the day here (you may attend only a part of it).

Presentations are given in French and include:

• Continuous Inspection with Sonar, by Olivier Gaudin (SonarSource)
• Managing ones Technical Debt with SQALE, by Jean-Louis Letouzey (inspearit)
• SQALE deployment at Société Générale, by Christophe Lallement (Société Générale)

Inscription here.

Thanks to the  « Poitou Charente Java User Group », the presentation (video and slides in French) has been recorded and is available here.

This is an impressive (150 pages) and very interesting work that I recommend.  Here are some extracts of the executive summary:

This project investigates the usability of the SQALE method at software company Info Support BV.
This method allows Info Support to measure the quality of Java and C# source code. We learned that
SQALE, as implemented in the Sonar tool, provides a workable method to perform this quality assessment for projects of both languages…
…
The investigation was performed by correlating SQALE quality judgments of 9 Info Support managed software projects with two types of validation data…
…
This leads to the conclusion that in general, the methods provides quality measurements that are valid. A number of side nodes should be made:
1. The method configuration is very flexible, and configuring is therefore a difficult task. This thesis suggests a number of options to enhance the configuration and possibly further increase correlation with validation data;
2. A higher correlation coefficient was found to not always imply a better configuration quality.
A starting-point configuration, consistent with the Endeavour rule set, and the use of a continuous improvement procedure is suggested.
The choice for the SQALE model and Sonar tool followed from a literature review and free search on
the internet, respectively. The method allows Info Support to not only determine the overall quality,
but also provides a rating for four important quality aspects, consistent with ISO 9126…

The thesis also contains some proposals for extending the SQALE methods.
These proposals have been taken into account within the new version of SQALE (coming soon).

In theory, the method has been developed for such a context. All SQALE concepts are generic. The underlying concept of technical debt is understandable by all levels of an organization’s hierarchy. For deployment in the large, SQALE does not require days of training. So, the only potential issue for deploying SQALE in very large organizations may be related to tool support. Are there tooling solutions for supporting SQALE on very large organizations? Here is a practical answer:

One organization (one of the largest banks in the word) has deployed the SQALE method on its entire application portfolio and its worldwide development team. The SQALE tool in place supports:

• 4 different languages
• 4,000+ applications
• 30,000+ developers
• 240 Millions lines of Code

So, yes, SQALE does scale !!

In an ideal world, where projects have the time to fix all the violations, the only good and helpful question is: How much to fix all of them? That is exactly what the SQALE Quality Index tells (SQI = Technical Debt). Based on such measure, the development team can update its planning and achieve the functional and quality goals of its project.
But, in many cases, especially with legacy code, the budget is not available for paying off all the accumulated debt. Then, other dimensions, points of view are needed to make the best compromise.

Following brainstormings, discussions with users, partners and colleagues, we end up with a new concept, a new index and a new indicator.

A new version of the SQALE Method Definition Document is under final review. Stay tuned!

22nd – 27th August 22-27 / Nice, France

“The SQALE Analysis Model: An Analysis Model Compliant with the Representation Condition for Assessing the Quality of Software Source Code”

Download

Download