SonarQube, commonly referred to as Sonar, is a freely available tool used for measuring code quality. It quickly became a favorite in the software craftsmanship universe. However, we are witnessing common pitfalls in its usage. While this tool is excellent, it can also lead to some very bad practices.
Rest assured, this article is not an attack on Sonar (SonarQube); this tool is excellent, and its popularity is well-deserved. If you’re not familiar with it, SonarQube provides dashboards for tracking the quality of the source code that constitutes a product in development. With just a few clicks, its users can access a wealth of additional details to help them pinpoint areas for improvement. This is ideal for maintaining technical excellence throughout a product’s development.
Sonar (SonarQube) – The Pitfalls
However, I see many pitfalls in the use of this tool… or, more precisely, in the enforced use of this tool.
In some organizations, the tool is simply imposed on teams by “craftsmen” teams… But even worse, all tracking indicators are enforced. While these software craftsmanship teams should ideally have an agile mindset, they are pushed into an ITIL mindset.
But why impose its use?
The root causes are ultimately very similar to those where Scrum teams are forced to provide “precise” velocity tracking!
Companies use these indicators to:
- Monitor the technical quality of teams.
- Make comparisons between teams.
- Review the status of certain providers.
- Remind the team of its obligation to deliver quality.
- …
In short, the use of Sonar (SonarQube) is unfortunately often driven by very wrong reasons. Teams lose their autonomy, the presence of providers is (unadmittedly) conditional, and clever individuals can achieve good results with mediocre code… Because yes, any system can be manipulated.
When I see that some companies require teams to undergo an audit by a software craftsmanship expert… it’s simply forgetting agility itself… and, in my opinion, we can no longer even talk about software craftsmanship!
So be aware, this is not the case in all companies!
So how should Sonar (SonarQube) be used?
SonarQube should be a tool available to every team that believes it will help improve the quality of its work. We don’t impose it; we provide the solution.
Thinking that imposing a tool will ensure quality is a mistake! There is a higher chance that these quality indicators conceal a disastrous reality.
On the other hand, a team that wants to use Sonar (SonarQube) has three times the chance of producing clean code. Why? Because they are motivated by their choice to monitor their work.
Software craftsmen should make themselves available to help those teams who would like assistance in their continuous improvement efforts. It’s in this context that technical coaches can be very effective.
Imposing it on a team will be nothing but a façade… and the resulting indicators will confirm manipulated numbers while concealing a much graver reality. We’re talking about watermelon metrics!
Indeed, Sonar (SonarQube) is an excellent tool but can become a curse when enforced. Let’s stay agile and truly benefit from what this tool can offer!
Be the first to comment