if you have a superior that trusts in Sonar 100% and trusts you and your fellow developers very little (unwilling to delegate permissions, decision making)… I think that’s the root of your problem
You make a fair point that anyone who uses a tool and does not understand is part of the problem. However, if the tool could be easier to understand, that could go a long way to addressing that issue.
Respectfully, the root of the problem is that SonarQube is not clear to everyone who uses it. Specifically, it offers little towards gauging what is important and and what is not. Programmers have been engaged with a tug of war with management since the dawn of the digital era. Managers, who don’t understand coding well enough to police it, are now offered Sonarqube as a policing tool. They are given a bat to hit programmers over the head. This has an easy metric for determining perfections – 0 issues found. It’s a managers dream – a computer that sums up everything you need to know in one number. If you give someone a bat, they’re going to use it to hit things. It’s pretty simple.
The number of issues found in your project is similar to likes on social media – it’s a badge of honor to show off to all your manager friends. I have a coding library that’s tens of thousands of lines. Military Standard data types are defined by two numbers, so my (Java) class names end with something like “_1234_567” Like a good programmer, my fields and getters follow the same naming pattern.
This violates S101, S116, S100, S101 for a total of 4.7k hits. This has caused everyone to freak out.
The OP point is well taken, that if I had an opportunity to add some structured comments to that report before a manager read it, the sky would not be falling. Now I am having trouble explaining in meeting after meeting, “we violated 4 MINOR rules on purpose. So if we ignore those rules like we’re supposed to, the 4,700 hits go away.” To which they respond, “You want us to cover up 4,700 hits?”
Clearly, it’s a major problem that they don’t understand a minor sonarqube finding “may slightly impact developer productivity” and it may also not affect quality.
So thanks to Sonarqube, I am going to have to make my code unreadable to a human in order to please management, which means INTENTIONALLY creating a mountain of technical debt. But that’s okay, because Sonarqube doesn’t count it.
Sonarqube exacerbates the problem of communication with management; it does not help it. The problem is how the information is presented. As OP pointed out, Programmers don’t have an opportunity to respond proactively to the issues. It’s fair to blame managers, it also fair to blame the bad information they are given to make decisions. For example, your issue count could be broken down into “must address” and “not urgent” or the like. It could further have something like, “4,712 issues have open discussions, here is a link.” The idea that a single number could sum up technical debt is simply dangerous. It encourages people to NOT investigate and learn more. It encourages people to not listen.
“Dude, look, it’s really simple, your project has 4,700 sonarqube findings, everyone else has less than 100. This is a job performance problem.” – Overheard in a meeting
Finally, I have a question. Are there articles posted by Sonarsource telling managers how to interpret sonarqube results properly? I’ve been scouring the web for “how to handle minor sonarqube issues best practice” and found nothing useful to my case. I’d welcome knowledge if anyone has any.