It is sometimes necessary to change the maintenance mode of a legacy application and switch it to an agile mode.

In this case, we must ask ourselves whether the source code of the project in question does not contain too much technical debt inherited from years of maintenance. If the inherited debt is too high, it is likely that it does not lend itself to an agile maintenance mode. How do I know which applications will be eligible to a maintenance type change, and those who do not?

We will see that the SQALE method provides a real help to such kind of decision.

What we want to avoid is that the poor (or very poor) quality of the application source code hampers the maintenance activities of the team. In this case the maintenance team will be far from reproducing the expected productivity achieved in other agile projects.

In a SQALE quality model, the first three expected quality characteristics (those shown at the bottom of the SQALE pyramid) are testability, reliability and changeability. An agile team performs cycles where activities of testing, debugging and change keep coming at a high speed. Their velocity depends mainly on their productivity for these 3 activities. The part of the technical debt that corresponds to these activities is thus the main concern. Other parts of debt such as that related to performance or safety will have a very limited impact on the team’s productivity.

In the SQALE method, the debt specific to these three characteristics is called SCCI (SQALE Consolidated Changeability Index). This index represents the « agile debt » of your code. When you divide this value by the size of the code, you get the density of this debt. This index called SCCID (SQALE Consolidated Changeability Index Density) represents the « agility » of your code.

If you look at the two SQALE pyramids below (which show the distribution of technical debt according to its impact on the life cycle activities), it is clear that the two projects have similar amounts of technical debt but very different distributions.

In one case (Application A) the portion of the debt which is relative to the “agility of code” is relatively low; in the other it is rather high. In the second case, it will be probably beneficial to refactor the code before maintaining it in an agile mode.

It takes some calibration effort to know which threshold should be used within a specific organization and a given context, but this dedicated SQALE index is of very obvious interest for such type of decision.

SQALE Pyramid samples issued by Sonar