Gamifying Code Quality

I have struggled recently at work dealing with a very large legacy code base that has a very long history. It was built when tools and good practices were quite different than today. So how do we measure our code quality and go about improving it? Several tools are available for most programming languages which can scan the code and provide you with a list of things you can fix. On this legacy code base the list was huge, it just felt depressing to see such a large list. The list contains ways to improve readability, consistent style, and potential vulnerabilities. If I was to fix all of the recommendations it would make adding new features and fixing bugs much easier.

I will share with you how I have tricked myself into getting excited about improving the code quality and how I went from malaise to excitement by employing a little bit of gamification.

So why would you want to improve your code quality? It makes maintaining the system and fixing bugs and future feature changes much easier.

Trying to convince your organisation that you should spend a few sprints to with this nasty thing called “technical dept” never goes down well. They see it as missed time that the developers are moving bits of code around while new features are not being released and bugs not being fixed.

If you are fortunate enough to convince them that it is a good idea and to spend the much needed time and embark on the quest then you quickly realise that the task is much bigger than you initially realised and by day 2 you don’t have much to show for it. Sound familiar?

An alternative approach is to think about code quality as you create new features. Just like a home loan, you don’t pay it off all at once instead, you pay it in instalments and slowly reduce your dept. This way, every time you build a new feature or bug you leave the code in a better state than when you started.

So how do you measure your overall code quality and create a baseline to measure from? Code quality is historically a hard thing to measure but for most programming languages there are now tools out there that can provide a report based on community code style guidelines.

In the ruby language world, there are static analysis tools like: flog, brakeman and rubocop. Running each of these tools gives you a big list of recommendations to improve your code in your project. This is very useful to see the impact that your change has to the code quality over time.

The tool that I am currently using for this has changed the game is code analysis tool from Code Climate and a recently added integration in GitLab Enterprise where it will show you this information in your merge requests. Since your merge requests are your source of discussion and a quality gate this is a great place to see the code quality impact this code change has on the project.

You can also do this in GitHub and directly. Since I work in a corporate environment where we need to keep our source code within our internal network, we use GitLab.

By adding a new task into your GitLab CI pipeline you can have GitLab automatically run code quality checks on each new merge request as soon as it is created. It will then show the results of this check compared with the branch that you are merging to and quality that has increased or decreased by adding your proposed changes.

After I configured this and later saw the impact every time I created a new merge request, I could see where I was improving things and where I was taking shortcuts and reducing the overall quality of the project. I saw green and red and the reward centres in my brain fired up trying to increase the amount of green.

It has also helped with doing code reviews with junior developers (link to another post) and I can have discussions around the different code quality metrics and why they are important.

By making code quality visible to everyone in the team by showing the change in quality for each new feature, we bring code quality into the conversation for each new feature and reward developers that improve it any time they modify the code base. This makes adding new features and fixing errors much easier.