In order to estimate the cost of refactoring our Legacy application, I will use the plugin SQALE of SonarQube, more usually employed to measure the technical debt.

We have already presented this plugin with a PL/SQL Legacy application. So just remember that the SQALE plugin is based on the SQALE quality model, and I will also add, on a method to adapt the model by aligning it with various business objectives, the technology or the contexte of the application.

SQALE and Legacy applications

Today, any application over 3 years is considered ‘Legacy’, especially if it does not have unit test coverage. In this case, ‘Edit and Pray’ or ‘Change and run’, explains Michael Feathers in his book « Working Effectively with Legacy Code ».

So you understand that we will not use the SQALE model in the same way for a J2EE application that is three years old, or our Word 1.1a application in C that was developed 20 years ago, or an even older Cobol application that has gone through the hands of several different teams, and some possibly offshoring.

We must also consider the type of application: here we have an office software sold by an editor software, and it’s not at all the same as a J2EE application developed in-house to meet business needs or based on a software package such as SAP. For example, our application is written in C and uses no database: factors like ‘performance’ and ‘security’ will not have quite the same weight as a traditional application to manage the business of a company.

SQALE and the monitoring of technical debt

Another factor to consider: as explained by Freddy Mallet from SonarQube in this video (in french) : « Technical debt means to avoid waking up after 5 years with a code with which we can no longer do anything without it costing us an arm and a leg ».

A common use of the plugin SQALE is to monitor and control the technical debt over the versions, in order to prevent it to go beyong a threshold where it starts to become unbearable and too expensive. Or, as explained in this post : « don’t start mopping the floor before you’ve plugged the leak ».

In our case, we only have a single version, so I will again point out that our use of the SQALE plugin is specific to our goal of evaluating a refactoring effort, without a personalized model but proceeding directly with ‘out of the box’ results .

In the context of this article, I will present these results in order to illustrate the approach to estimate the cost of refactoring a Legacy application. Estimation done ‘a priori’, even before to consult the project team or the management about this refactoring, but with the intention to list some elements to present during a future meeting.

SQALE in the SonarQube dashboard

I configured my own dashboard in SonarQube with a widget to display the following data from the SQALE plugin:

Figure 1 – SQALE data on the technical debt of our Legacy application

1 238.7 days to reduce the technical debt. With a rate of 18.5 working days per month, this represents 69.4 months and, for our team of 5 people, 13.9 men/months.

So it takes almost 14 months to our project team to overcome this technical debt. Needless to say that this is not acceptable for the management: it means to stop any development, any new release for over a year. No customer, no user would agree to such a decision.

However, our goal is not to eliminate 100% of that debt, but to make an effort to reduce it so that the burden of the debt becomes acceptable, and the corresponding reduction in maintenance costs becomes greater than the cost of refactoring. Indeed, the decision whether to make a refactoring is usually based on a ROI (Return On Investment), and having the gains in maintainability exceed the cost of refactoring.

Is it possible to consider a reasonable effort, with limited but specific actions, and a return on investment? This is what I will look with other data configured in my widget.

First, I see that the ‘SQALE Rating’ is equal to ‘B’. This shows the weight of technical debt in relation to the whole application. Another SQALE widget in the SonarQube portal gives me the distribution of the technical debt on different files.

Figure 2 – File Distribution by SQALE Rating

We have 12 files with a very high technical debt, and if I list these files, I will find some programs previously identified as the most complex, the largest in number of lines of code (LOC) and/or with very complex and large functions.

Figure 3 – Highest SQALE remediation costs

Another way to check the distribution of technical debt on all application files: the Bubble Chart. I love this one. I can choose any metric I want and cross them:

• Technical Debt in days on the Y axis;
• Number of lines of code on the X axis;
• Cyclomatic Complexity for the size of the bubble.

Figure 4 – Technical Debt x Cyclomatic Complexity x Lines of Code

We can see, on this figure, the file ‘fltexp.c’ with the highest technical debt for a program – 23 days of refactoring – spread over 2 600 lines of code and 740 points of Cyclomatic Complexity.

Some will say again that the number of lines of code (LOC) is not a reliable measure of the size of an application, but after playing with different combinations of metrics, it is still the most correlated with the technical debt, and therefore a factor to take into account in order to understand it.

For example, in the next Bubble Chart, I chose the Cyclomatic Complexity (CC) by function as a measure of the size of the bubble.

Figure 5 – Technical Debt x Cyclomatic Complexity/Function x Lines of Code

The file ‘RTFOUT.C’ that we have presented previously, has the most complex function with 355 points CC, but also another one with only two points of CC. The average complexity of this file will be (355 + 2) / 2 = 178.5 points CC, as shown above the graph.

I also displayed in this figure the measures for the file ‘fltexp.c’ which we have seen previously (Figure 3 earlier), with the highest technical debt and 740 points of CC, but spread over a larger number of functions, since the average CC by function is about 16 points.

This graph is interesting, but I think that it is less useful than the previous one, which was more meaningful and relevant to the effort of refactoring for each program and the entire application. Anyway, we can see that we have in SonarQube different tools and widgets to imagine and investigate different courses of action.

With these widgets and these data from the SQALE plugin, I know:

• Which files have the highest technical debt: no surprise, these are the heaviest and most complex files of our application, as previously identified.
• The refactoring effort to remove the technical debt for each of these files.

But again, this effort is too important to be considered as such, and not necessarily needed because we do not want the total eradication of the technical debt, but a refactoring based on actions with a cost of reduction of the technical debt as low as possible for the maximum benefits.

Our next post will be devoted to the presentation of these actions and their estimated cost.
See you soon.

 

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