A game of refactoring: Studying the impact of gamification in software refactoring

I study computer science because it was the one subject that I was curious about in high school and still have lots of questions about. The latest ones, I ended up presenting at the RefTest Workshop in “XP 2016 – EDINBURGH”. The content is summarized in a paper called “A game of refactoring. Studying the impact of gamification in software refactoring”, which I wrote with Leonard Elezi and members of the ANSYMO (Antwerp System Modelling) research group.

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. Martin Fowler 2002

Think of it as text editing. You wrote your first draft and you need to restructure and fix sentences here and there for the final version. It’s the same we do with code. We arrange classes or methods (paragraphs/sentences) logically so that the code (text) is easier for others to read and understand. All of this without changing the final output of the code. It also reduces bugs, errors in the code. This is a very repetitive, even boring task for a developer considering most of them understand their own perfectly working code.

If it’s not broken, why fix it? There is never a one-person team working on a project. IDEs offer automatic tools to perform refactoring and the other authors and I thought of a way to encourage their adoption. We developed CodeArena, a gamified tool for promoting the adoption of the refactoring capabilities of Eclipse. CodeArena pushes developers to refactor by creating a competitive environment where each refactoring is rewarded. We then conducted an experiment on 12 undergraduate students, who were given an assignment to refactor a Java project in an eclipse environment where we had previously installed CodeArena.

It is interesting how in every gamified application the same problems come up. The novelty factor where the users are initially very enthusiastic for the new tool/game and later, while they get acquainted with it, the motivation declines. And the cheating problem. There will always be users who want to bypass the rules for faster progress and not focus on the real task at hand. To address the first, constant change should be done to the tool and the second problem can help you find innovative ways in doing so.

Another observation during this experiment was the intrusiveness and gamification correlation. You can’t have both. We didn’t want the developers to be bothered by the tool and we gave minimal feedback to their progress, unless they opened the view to check this in real-time. The minimal feedback resulted in few students not noticing it at all.

More specific observations, proposed and experimented solutions for this study on gamifying refactoring you can find in the paper. This was an amazing opportunity given to a master student by the University of Antwerp which set my thesis expectations quite high. Next I will work with mutation testing, another very useful but no so popular technique. I could not continue my education and work at the same time if it weren’t for the flexible hours we have at 4C. It’s a little much I have under my sleeve but I have a lot of support.