Code Quality Game
Applying Gamification to Sonar (SonarQube) to encourage developers to pay the Technical Debt.
This project implements a simple web page that shows a ranking of developers by how much technical debt they are fixing on SonarQube (a.k.a. Sonar). It promotes a friendly competition thus solving one of the main problems of fixing legacy code: it’s boring (believe me, I’m a developer).
It accomplishes that by connecting to your SonarQube server, which may be privately hosted or cloud-based (sonarcloud.io). Given a list of user alias that you have to provide, it retrieves the issues that have been fixed by each one of them, converting them to points and presenting that in a ranking. The game is much better when you play as a team, so you can also group users together in the configuration to make the competition much more appealing.
Getting the game
The easiest way to get the game up and running is to follow the instructions on the repository’s
As explained above, every user’s SCM account alias should be listed in the game configuration. Normally, these user aliases are the ones used in your SonarQube server too; that’s the way the game gets individual data from the server. Sonar doesn’t know anything about teams so this part is processed by the game itself, aggregating scores of users from the same team before displaying them on the web page.
To credit score for fixing a problem in Sonar, the user must have that issue assigned. Usually, issues in Sonar are assigned to the person who introduced them. However, since we’re trying to fix the legacy code and not new Sonar issues, the assigned person won’t match frequently the user who fixed it. Users who want to claim a fixed issue should go to SonarQube UI and assign it to themselves using the dropdown in the issues search result (see picture above).
The main goal of this application is fixing Legacy Code (old code that is difficult to maintain, not readable, and error-prone). You need to set a reasonable value to this property in the game configuration. Users will only get score if the issue they’re fixing was introduced before that date – thus this date is considered the one in which you started doing things properly and not allowing new important Sonar violations.
Don’t go cowboy-fixing
Make sure that the violations you fix don’t have an unknown, expected side effect. Sometimes it may happen that you refactor your code to fix a Sonar issue and you introduce a bug that is much worse. To avoid it, always check that the code you’re changing is covered by Unit Tests. If it’s not, then you have a good opportunity to implement them before going ahead.
Right now there are two badges that you can win.
- Early Bird. Configure the
earlyBirdDatein the properties file. Those players who solve issues before that date will get that badge. This is to promote a better adoption of the game.
- Unit Tester Ranks. These ones are related to the Unit Test Coverage and there are different ranges. If you assign to yourself issues about code coverage and fix them, you’ll get badges as soon as you pass 1, 10, 25 and 50 issues.
The game is a work in progress, and I’d appreciate if you give me some feedback. Do you have any ideas? Is there something that doesn’t work for you? Questions? Please open an issue in GitHub or comment on this page.
Are you interested in the story behind this project? Why did I start it? Check out the post A gamification experiment with SonarQube.