Why Developers Love SonarQube
We’ve seen a lot of tool transitions across a large enterprise, and one of the coolest examples was changing the opinion of the company we worked for regarding source code analysis. We had a tool that was under-licensed, slow, ineffective, and largely ignored. At best, it was a check box labeled “we’re definitely secure, you guys!” that everyone on the ground ignored.
The purpose of a source code analysis tool is to look for the following in code:
- security issues
- likely bugs or logic issues
- inefficient or shady development practices
The tool our company had, however, was poorly supported with an unclear process for adoption and usage. The UI was hard to navigate and it didn’t support all of the languages that we used – as a result, almost no one used it and the people who did struggle to work with it got little value from it.
Bad Tools, Bad Process, Bad Governance
The worst thing you can do in governance is say you’ll enforce something (especially bad if this is an enforcement promised to an external authority, like an auditor) and then implement that decision with an onerous tool that everyone hates that doesn’t solve the real issue – and then, for funsies, support that tool poorly and don’t really explain how to use it in day to day processes.
Why SonarQube
Note: We got zero dollars or…anything, actually, for this post. We just saw how much the nerds we love, loved SonarQube – and some of the reasons why were interesting from a culture nerd perspective. If the SonarQube people wanted to give us some money for this post, we’d probably be just fine with that. We also accept swag as payment!
The best parts of SonarQube, from a developer’s perspective:
- early “hey, you guys have a bug.” Fail fast.
- integrates nicely into CI/CD pipelines
- built by developers, for developers
- free and open source, with paid support if that’s your jam
- has great enterprise support and plugins, including functionality for many many coding languages
It’s clear to users that value is delivered quickly and clearly.
It also has a nifty dashboard for each artifact scanned that tells people bugs, vulnerabilities, code smells (hey, you coded this silly, please fix?), and unit testing coverage. It makes a game out of code quality – it makes it an interesting, measurable challenge.
The Game of it All
Gamification helps to clarify purpose.
Gamification reinforces the actions that move a person or team toward fulfilling their purpose.
Translation: gamification helps teams focus on what their purpose is, and it also shows with clear feedback and metrics (scores!) if they’re successful at fulfilling that purpose or not. In that way, gamification helps to clarify purpose – it helps teams focus on what their purpose is, and it shows with clear metrics (scores!) if they’re successful at fulfilling that purpose or not. Gamification gives people clear goals to attain, and fast feedback on if they’re attaining them.
In order for this to be successful, leadership has to make it clear that people shouldn’t be afraid of missing those goals, of “losing” the game – but if they do that, people will try to hit those goals because…it’s fun. People will also try to hit the goals because they love what they do, and because hitting those goals, the game of it, confirms that their actions fulfill their purpose – they know that they’re doing something important.
Thanks SonarQube!
There’s a whole world of tools out there that enterprises can purchase and use, and it requires a combination of good tool and also good implementation for them to be successful. Most of the time, the implementation is more important than the tool, but sometimes tools are exceptionally bad (and no implementation can save them) or exceptionally good (and the implementation is easy). SonarQube falls into that last category, and it was a blast to watch people get excited about a process that they previously hated.