As explained in the previous post, we have not customized the SonarQube Quality Profile and the SQALE model for our Legacy application, depending on its context, as it should be.

In fact, I use the results ‘out of the box’ in order to illustrate one possible approach to estimate the cost of refactoring this application, and present some ideas to the project team and management, for further actions – or eventually see them rejected.

In other words, it’s the process that interests us more than the results of our application, at least in the context of these articles.

What can we propose, based on the SQALE plugin?

Address the most critical defects

The first thing I can see with the widget that I customized (see Figure 1 – SQALE data on the technical debt of our Legacy application) is that it costs us:

• 59.6 days to address issues of Critical type and beyond, that is to say Critical and Blockers.
• 1 115.6 days to address issues Major, Critical and Blocker.

The same information is provided by the following widget:

Figure 1 – SQALE Remediation Costs

The dark blue area on each of the horizontal bars in this graph corresponds to the previous bar, so that we have a cost per criticity and the total cost, as displayed in the two right columns.

We had seen previously that we had no defect on Blocker type rules and 753 defects on Critical rules, most of them concentrated on two rules.

Figure 2 – Violations to Critical rules

The figure below lists the files containing these defects and their remediation costs:

Figure 3 – SQALE Remediation Cost – Critical and Blockers

I can open each file in SonarQube, and choose to view only a certain kind of Issues. The following figure shows the Critical issues in the program ‘fltexp.c’.

For each of the 16 Critical defects in this program, I can see:

• The line of code.
• The cost of remediation of each issue, as configured by default in the plugin SQALE: 1 hour in the first case (MISRA C++ 6-6-1) and 15 minutes in the second one (MISRA C++ 5-14-1).

Based on these numbers, I can propose a first action of refactoring these components with critical defects for a total of about 60 days, or 12 days for a team of 5 people.

In reality, I would work with the project team to estimate the defects they see as Critical (or Blocker), the time they deem necessary to resolve each Issue, and the set the Quality Profile and the SQALE model based on their observations.

Bring back the SQALE Rating at A level

With the widget that I customized (see Figure 1 – SQALE data on the technical debt of our Legacy application), I can also see that it costs us 291.9 days to bring the SQALE Rating from B, its current level, to A. the SQALE Rating measures the debt burden in the application, as follows (in our case):

• B: between 10% and 20%.
• A: less than or equal to 10%.

With a rate of 18.5 working days per month, these 291.9 days stand for 15.8 months in total, or 3 months and 3 days per developer for a team of 5 people. If I add a charge of project management of 20%, which is the usual figure when you forecast a planning, we get as far a 3 months and 15 days per developer.

We have seen that writing characterization tests required about three months, with some days for project management, which is very acceptable in the context of a knowledge transfer. If we add another 3 months and some days, the duration of our project of refactoring is more or less between six months and seven months, which is correct if we consider that we have improved the reliability of our application with unit testing and bring it back to a very decent level of technical debt.

In reality, it is very difficult for the management to justify to the users that the development of new versions is paralyzed, and there will not be any evolution, or very few corrections, during that period. I know nothing of the backlog in terms of user requests, changes, and tickets, as well as the workload of corrective maintenance per month that we should take into account in planning our refactoring: so I will just considere we have these 292 days and I’ll try to optimize them in order to build the best possible proposals of action plan, at best acceptable, at least worth considering.

The SQALE pyramid will help us choose among the different categories of violations of best practices.

Figure 4 – SQALE Tecnical Debt Pyramid

Each of these high level factors has a number of ‘characteristics’ that will gather different metrics in this category. The following figure shows the SQALE configuration screen in SonarQube, that we can use to set the cost of remediation for each violation to a programming best practice  within each category, in this case the ‘Characteristics’ for Testability.

Figure 5 – Configuration of the technical debt for each rule in the SQALE model

I have no rules for Reusability in this Profile for this language, which explains why the technical debt is equal to 0 on this factor (see Figure 4 above).

The Portability characteristic has a unique infringed rule, for a technical debt of 3.5 days, but this rule is important only in the case of rewriting the application in C++. To be taken into account as part of a reengineering then, but not for a refactoring.

Figure 6 – A unique rule for Portability

It’s the same for the rules on Testability (see previous figure 5) as ‘Avoid too complex file’, ‘Avoid too complex function’, the number of parameters of a function or the use of ‘goto’ and ‘continue’: a refactoring for this kind of defects requires a redesign of the application, so once again, for a reengineering. Because if you need to rethink the design and architecture of your application in order to better distribute the complexity, then you can take the opportunity to rewrite it in an object oriented language like C++, and benefit from inheritance, encapsulation and polymorphism.

Same for the Changeability. The following figure shows the SQALE Sunburst with:

• At level 1, the different factors Maintainability, Testability, Reliability, etc.
• At Level 2, the characteristics within these factors, as Readibility and Undestandibility for Maintainability.
• At Level 3, the rules within each characteristic.

Figure 7 – Rules for Changeability in the SQALE Sunburst

We can see from this figure that the 13.7 days of technical debt for Changeability are related to a single rule about nested ‘if’. The more ‘if’ nested into other ‘if’, the more difficult it becomes to understand the code, and the highter the risk of introducing a bug when a change is made to the code.

Note that such a rule could well be found also in Understandibility. In fact, many rules in the Maintainability group are are often candidates for Changeability also. Reason why, again, it is recommended that you customize the SQALE model according to your own use case, and not to use it ‘out of the box’ as I have done for this article.

In any case, these defects on nested ‘if’ are well in the target of a refactoring, and we can include these 13.7 days in our action plan.

In the following figure, I inserted (by copy/paste) different measures:

• Maintainability: 738 days of refactoring, divided into …
• 505.6 days for Understandibility and 232.3 days for Readability.

Figure 8 – SQALE Sunburst for Maintainability

We can see that the cost of remediation is higher on rules that are not really critical. 20 years ago, Microsoft did not use the currently usual naming conventions for macro, which is neither surprising nor very important, and the resolution of these defects at a cost of 128.1 days will not really provide us enough value to consider such an action.

It’s the same for the use of braces with ‘if..else’ which in fact lists a lot of ‘if’ on one unique line, so very readable and very understandable. Little benefit for a very high cost.

No, there are better than defects of Maintainability to optimize the 292 days we have, in order to bring back the Technical Debt to level A. We can see from the SQALE pyramid (Figure 4) that defects on Reliability require 291.8 days of refactoring, which is exactly the number of available days that we have.

In addition, these are errors that affect the reliability and robustness of the application, and thus present a risk to the user or the customer, as opposed to defects on Maintainability that will certainly weigh on costs of maintenance, but will never cause bugs. Obviously, this again depends on the orientation you want for the SQALE model, customizing it towards user satisfaction or rather in favor of preserving your budget.

First, I can see that the 59.6 days to settle violations of type ‘Critical’ (see Figure 2 above) are already present among these Reliability rules. The following table shows the different rules and cost of remediation for this factor.

Table 1 – Costs of remediation of defects on Reliability

All these rules aim for improving the robustness of the application and to reduce the risk of bug. If I add the 13.7 days for Changeability, to remove the nested ‘if’, we go up to 305.5 days, or 16.5 months or 3 months and 6 days per developer (excluding project management).

That said, the workload for managing the project should not be heavy, since the action plan, from an operational point of view, is already in the SQALE plugin. We have seen (Figure 2 of the previous post) that we had the distribution of programs across the SQALE rating. In the following figure, I can see the list of the files with the lowest rating.

Figure 9 – SQALE Rating of files

We can see that we have a lot of .h files, just because of the large number of violations to the rule ‘Macro names should comply with a naming convention’. Hence the importance again to customize the Quality Profile and SQALE model rules, in this case to deactivate or to lower the criticity of this rule.

Managing the Technical Debt in real-time

Addressing the most critical defects has a cost of 59.5 days, about 12 days for a team of 5 developers.
Reducing the technical debt of our application to bring it back on a ‘A’ SQALE Rating requires about 300 days, over three months for our team, an effort that managers or stakeholders are likely to consider too high.

An intermediate solution would be to manage the technical debt partly in real-time, that is to say, parallely to the application maintenance. Every time a developer will have to make a change or a correction in a program, it will also use the plugin SQALE to verify:

• If technical debt increases. This is the main use for a developer of the SQALE plugin, as we discussed in the previous post: Avoid regular inflation of the technical debt and ending up in a few years with an unmaintainable application .
• If it is possible to reduce it while realizing the changes that he must achieve, focusing on the rules that we have defined as critical in the SQALE plugin.
• If he has not increased the technical debt after implementing these changes.

No need to ask the developer to respect more than 10 best practices: beyond that, it becomes too complicated to remember all the rules. It also depends on the experience of the developers and their level of knowledge, if not of maturity on best practices. But even the most experienced developers can make mistakes by lack of attention and will occasionnaly let pass some defects. Hence the importance of monitoring regularly the technical debt.

Obviously, the choice between these different proposals of action plans will depend, not only of the effort, but also of what we can gain: can we propose a hypothesis of ROI to the management ?

As this post is already very long, I will finish this article about ‘Refactoring with SQALE’ with a summary of our proposals and an attempt to calculate a ROI. In the next post.

This post is also available in Leer este articulo en castellano and Lire cet article en français.