Developer’s idol – Gamified code reviews

At TechEd this year in Amsterdam I got the opportunity to arouse Marilyn Pratt’s curiosity for some gamification we applied to our development process and she asked me to write a blog about it.

And if someone like Marilyn asks kindly, you cannot reject. So let me introduce you to a game we played among the developers. Let me first explain to you my motivation:

As in every custom development, one somehow has to ensure coding quality. Usually, this leads to code reviews which are one-on-one discussions about one specific part of an application which the culprit (developer owning the code) has produced. The sheriff knows how it’s supposed to be and documents the failures (such as not adhering to the most important naming conventions) neatly in one or the other form of virtual paper. This artifact of bad style is then passed on to the quality team which magically somehow derives figures from that which are – well, we don’t have to proceed with that; I believe you got my intention and you are surely figuring: I don’t like it too much. And don’t tell me that everything will be better with code inspections and an objective reader! It’s not that I believe that there should not be something like responsibility for code and that it’s not good to check the quality by someone who should know it better. I simply don’t like the side effects (given non-perfect code, of course):

1. In a review, it’s really tricky not to blame the author. Particularly for me: I’m very passionate when it comes to code and knowing that the person sitting opposite to me has hurt the system with the way he implemented brings out the Batman in me – or at least Robin (Hood). As I’m emotional too I have to really control myself not to jump at the poor code-owner or at least yell out loudly (though I managed not to yell a people anymore).
   All this is not only bad for the mood of the culprit, it’s also bad for the efficiency of the review: The developer usually either concentrates on defending, rather than on understanding my and the system’s pain or he completely gives up and simply agrees to everything I say – which has the same effect on not-learning.
2. Assuming that there is some learning within that session, this is restricted to the attendees, so usually two or three persons. Sharing the learning is an extra effort and leads to a continuously enlarged lists of Dos and mostly Don’ts which no developers looks at – before he’s “invited” for another trial.
3. The experienced reviewer is usually one of the key-resources of the project – otherwise, he’d not be the experienced one. And his time is valuable and very limited. Having that guy review one artifact of each developer sequentially means that the code reviews are effectively even more expensive than on paper. This corresponds to the last aspect of why I rant about that process:
4. Time. There is no spare time in a development project. Particularly not for the knowledgeable guy. From my experience, this is one of the reasons why reviews are skipped, shortened to duration where it’s not possible to really discuss and learn. Alternatively, they are being held toward the end of the project (into the component testing phase or even later, whenever seems to be “enough sparse time”). After the review, the poor culprit understands that he has misunderstood a general concept and has to change that finding in multiple resources which he has created during the last year and thus invalidates the first phases of testing.

Having experienced what I said from both sides, I thought about how I could change the code-quality-assurance in my project in such a way that I like it. So let me explain to you what are my objectives are when having code reviewed:

• Finding errors in code. Of course, this is one intention and I’m quite sure we all agree on that. But I’m talking about errors here. Not naming conventions – unless they produce the error of making the code hard to understand. And yes, we do have naming conventions, but let’s not discuss about that, as this is not core of this blog.
• Even more important to me: Sharing knowledge. Someone knowing why something is not good to do and what the alternatives are will not only like to correct his code, but he will also not do this again. And he will share his proudly acquired knowledge with others, if he’s an outgoing person.
• Having fun. This is a core goal of everything I do, so this has to be an objective of this task as well. And actually, it’s not difficult. Assuming that producing code is something a developer likes to do, he also likes to talk about it. Everybody likes to be engaged in something he likes to do and talking is one kind of engagement. It’ not only explaining why one has gone for one approach and not for something different, but also understanding concepts which you to be better at the thing you’re doing. This is also one major reason why a sports addict joins a sports club – to get better at your activity and to score the important points next time.
• Sharing pride. In a lot of code, there are not only places you’d like never to have seen, but also brilliant ideas and sometimes funky solutions which solve a problem in a veeeeery unique way (most probably this should be a place in your code which is introduced by a huge block of comments). Valuing someone’s brainy efforts and motivating with appreciation is something I believe should be part of every common code-reading.

This should be enough for explaining why I came up with the following idea in my project:

The game is set-up as follows:

1. The good, the bad, the ugly: One week prior to a common meeting, every developers starts searching the system for three samples of something brilliant, something that leads to an error and something which is strange but does no harm to the system.
2. The whole team meets in a game-show. The duration of the meeting depends on the size of the team. I experienced that about 20mins per developer are needed. This can be quite long for a bigger team, as usual plan for some break after 90mins.
3. One by one, each developer presents his three favorites and explains why his samples are most appropriate for each category. After each code snippet, the whole team is allowed to question the snippet or discuss about the presentation. Finally, each team member judges not only the quality of the sample, but also the quality of the explanation.
   Important: Identifying the owner of the samples is not subject of the game! Naturally, this will become evident during some discussions, but there are no points awarded or reduced for the fact of being the author of brilliant or crappy code.
4. The meeting ends with celebrating the winner – and with kindly asking the anonymous owners of the not-so-brilliant samples to clean up their deliverable.

We’ve played this game only once during our development so far, but I felt that it was working really well: We got rid of most bad aspects I ranted about and achieved what was important to me. Particularly the sharing of knowledge was much more intense and in fact, we had a lot of fun!

What do you think? Do you also play games as part of your development process or do you have suggestions for improvement? I’d be happy to read about it!