Last Friday, a blog post on Channel 9 announced Achievements for Visual Studio, an extension for the Microsoft IDE that tracks the actions of programmers as they write code and unlocks badges based on their behaviour.
Now that the concept of gamification has become (even too much) mainstream, it is not surprising that this is not the first time an idea like this is proposed. Jason Rudolph has published an excellent blog post about programming achievements. Websites like coderwall already inspect source code repositories on GitHub and others in order to build achievement-based profiles for coders. There even is an earlier project, called Strokes, that added achievements and challenges to Visual Studio.
Introducing mainstream achievement support right within the IDEs, however, can have a stronger effect on the way we write software, as those tools can inspect code right while we are writing it. The strong link between action and reward lead to a stronger feeling of accomplishment when we earn those achievements, and programmers are likely to be receptive towards game mechanics (most of us have a background as gamers). But there is more than that.
How it works
Most of the newly introduced achievements promote best practices, such as the Good Housekeeping group depicted below. Some of them are triggered by specific events, such as coding on a Friday night, while others take unlikely activities and award achievements just for the fun of it. The full list is available on this page.
There is also a more interesting set of achievements, appropriately called Don’t Try This At Home, which is way more controversial than all the others (and it resulted in a quite mixed set of reactions in the comments and on other blogs). Here are three examples:
The achievements in this group are awarded as a consequence of using some commonly recognized bad practice, typically something that results in unreadable or unmaintainable code. They are given a sort of negative connotation, since most of them are not not worth any points (and some readers even proposed to actually subtract points) but they are still called achievements, which will certainly lead some coders – typically the ones with strong collector habits – to indulge in bad practices just to get all the possible badges.
And yet, even this initial implementation is a significant proof of how such a system can be used to influence the way we build software, even if at a low level. Since programming is not just a game, let’s see if we can design achievements to actually help us writing better software.
Taking it to the next level
Regularly running static code analysis tools can give so many benefits that, as John Carmack points out, it is just irresponsible not to do it. However, especially with large and old code bases, even when such tools are used their output is neglected and they get discarded after a while. Often it takes the willpower of some good souls who choose to sacrifice their own time to fix all the defects that have been accumulating for months.
Gamification and achievements can be just the right nudge we needed to win the latent resistance towards static code analysis, as they can regularly inspect the code we write and give prompt, frequent and consistent feedback about how we are doing. But instead of presenting us with a flat list of warnings and notice, they can give us feedback in a more pleasant and personal way, as part of a wider system designed to add some fun to our chores.
The ideal system would be designed according to a few key principles, such as the following ones:
- focus on positive change – by rewarding updates that increase the quality of the code base, more than one-off activities
- use positive framing – instead of punishing bad behaviour (e.g. by subtracting points), encourage good habits that last
- make cheating unappealing – if too much importance is given to the achievements themselves, users may try to “game” the gamification system, engaging in fake activities just to collect all the possible badges, or to get a higher score (that is why I am not fond progress bars, percentages and the whole concept of “missing achievements”)
- reducing the number of warnings on an existing project
- adding comments and documentation to a previously undocumented component
- written a significant number of meaningful unit tests
- committing 50 changes without breaking continuous integration
As it often happens when games cross work and real life, ideas like this are bound to be controversial. On one side, we may see them as just adding some meaningless dimension to our day to day activities. On the other hand, we can benefit from the additional enthusiasm and motivation achievements can instill in us. Some people, like Reeves and Reed in Total Engagement (p. 169), even suggest that building skill- and level-based profiles of employees and coworkers can result in better performing teams on the workplace.
Personally, as someone who has spent a significant fraction of his own lifetime playing games, game mechanics can have a big influence on my behaviour and engagement (even if I try to be aware of that happening). I believe that a well designed system can help a great deal in making positive behaviours and habits come more naturally.
Maybe achievements will not be that relevant for expert coders who are already passionate at what they do but, if used effectively, they can lead newbies to invest more in learning best practices and mastering their tools. Indeed, inducing good behaviour is better than imposing it.
So, when can we expect to see something like this on other platforms?