Leverage SonarQube to Fix Technical Debt in Multiple Projects

SonarQube gives us a good and honest overview on the quality of our code. It’s most likely not as good as we hoped for and much work will be needed to get it to an acceptable level. But where do we start? And what can we do when we have many projects?

This post is part of the SonarQube series. You can find the other parts here:

• Part 1: SonarQube: Installation Walkthrough for Windows and SQL Server Express
• Part 2: Collecting Data on your Projects with SonarQube Scanner
• Part 3: Start Analysing Code with SonarQube
• Part 4: Fine-tune the Collection of your SonarQube Projects
• Part 5: How LOC is computed in SonarQube, NDepend and Visual Studio
• Part 6: Customise the Rules in SonarQube
• Part 7: Get SonarQube Ready for Production
• Part 8: Integrate SonarQube with Visual Studio Team Services
• Part 9: Integrate SonarQube with Visual Studio using SonarLint
• Part 10: Leverage SonarQube to Fix Technical Debt in Multiple Projects

 

Get an overview

The big benefit of using SonarQube with all your projects is that you have one place where all that information on code quality comes together. You don’t need to look at each project individually, instead you can look at all of them and let SonarQube show you where you should act first. You don’t even need to log-in to get a first overview on all the analysed projects right on the start page:

The developers behind SonarQube already spend time to classify problems. Bugs, vulnerabilities and code smells are the types you see when you look at your project. Behind those numbers are different problems that range from blocker to info. You even get an estimate on how much time it will take to fix those problems. All that is right there and waits on us in the “Issues” tab:

Spend some time to look through the numbers to get an understanding on how big your problem is.

 

Is it still getting worse?

Cleaning up technical debt that already exists is best done when not much more is added. If you fix two problems and get three new ones it will demotivate your team. Therefore, first make sure that the situation isn’t getting worse. Tools like SonarLint can help to shorten the feedback loop and improve the quality of newly written code.

If the quality continuous to get worse you better spend time with pair programming and code reviews to create a common understanding of code quality in your team. As soon as you all agree on the goal you can first stop adding more debt and then go and clean it up. It may take far longer than you expect, but keep patience and wait until this happens.

 

How much can you invest?

The overview in SonarQube helps you to calculate the estimated time to fix all your problems. Most often this number is much higher than what you can invest in code quality right now. Be honest about how much you can invest. If you don’t have any time to spend on reducing technical debt, then concentrate on not making the situation worse. That will be work enough.

If you have time to reduce technical debt you need to make it count. Even when you currently have enough time to fix everything, the rules evolve, priorities shift and new challenges arrive. Don’t waste time and start.

 

Where to start?

What should be done first depends on your situation. Do you prefer a clean project that is your showcase for code quality? Or do you want to fix the most important project first? While important sounds nice, there is the danger of endless arguments on which project is the most important one – time better spend with fixing the quality problems.

Fixing the biggest problems first is much better. We can use the classification done by SonarQube (or our modifications on the rule set) and don’t need to prepare anything in advance.

In my opinion there is one exception you should consider: Dormant projects that aren’t actively developed should be ignored. Spend your time on active projects so that you and your team can notice the changes.

 

Triage

Go through your list of problems in the Issues tab. Select the severity “Blocker” first and work through the list of issues. If you think they need to be fixed, change their status to “Confirm” and assign them to a developer:

There will be some that you don’t intend to fix. Mark them right now as “Won’t fix” so that they no longer appear as problems. That is done quickly and will help you to concentrate on the real problems.

The same should be done with problems that are false positives. They happen from time to time and marking them is a simple way not to check them again and again.

If you got to the end of all “Blocker” items, you can change the filter to include all with the severity of “Critical”. Repeat the steps from above and when you are done, do the same things with the “Major” and “Minor” issues. You can stop whenever the estimated time to fix those issues has reach your budget for quality improvements.

The rest of the items don’t get addressed right now. That may seem like a bad decision, but you do a triage because you don’t have enough time to fix everything. As obvious as this sounds, but not having time to fix everything means somethings will not be fixed. At least not now.

 

Reducing the debt

So far everything we did was preparation. Now it is time to fix bugs and reduce technical debt. Every developer can use the same Issues tab as before and select themselves as the assigned developer. In combination with the severity everyone can filter the items and get a list of problems they should fix next. They pick the first one and will find directly in SonarQube a description of the problem. Most rules include a solution as well, that can be applied without much changes:

You can integrate this work into your project schedule or dedicate an hour a day to work on these items. Depending on the size of your task list a clean-up afternoon once a week may be a better idea. I don’t believe in dedicated sprints to improve quality. They aren’t done frequently enough and if they finally arrive, more important tasks tend to pop up reducing the available time to a big extend.

 

Keeping track of improvements

The bigger the debt, the more work is needed to get rid of it. That may result in months of small improvements that are hart to track. A simple way to be aware on how this counter has improved is to measure it at the end of every iteration, define a goal for the next and create a graph on how this metric develops. It may look like a lot of work, but don’t underestimate the motivational aspect.

 

Conclusion

This post marks the end of my blog series on SonarQube. All parts are now in place to measure code quality continuously. The quality problems aren’t fixed by themselves, but this post gives you an idea on how that can be done. I hope you enjoyed this series and leave a comment on your experience with SonarQube and how you improve code quality.