While the benefits of code review are proven, documented, numerous and awesome, it doesn’t change the fact that most people, in general, don’t like doing it.
I guess code review just isn’t really all that fun.
So a few months ago, I broadcast the idea of turning code review into a game. It was my way of trying to mix things up – “let’s add points, and have reviewers/developers competing to be the best participant in the code review process”.
Well, if there’s one thing that my supervisor Greg has taught me, it’s how I shouldn’t rush headlong into something before all of the facts are in. So before I decide to do something like game-ifize code review, I should take a look at some prior work in the area…
Enter this guy: Sebastian Deterding.
In particular, check out the following slide-show. Flip through it if you have the time. If you don’t have the time, scroll down, where I get to the salient point with respect to game-ificating code review.
Here’s the slide-show. Be sure to read the narrative at the bottom.
The Salient Point
Sebastian seems to be saying that adding points to apps and trying to incite competition does not make something a game. If it did, then this should be countless hours of fun.
Without play, there is no game. Points do not equal a game. It’s not nearly that simple.
Free Pizza and Pop
I’m going to divert for a second here.
Last week, a company set themselves up a couple of booths in the lobby of the Bahen Center where I work. They were there to recruit university students to work for their company – either as interns, or full-timers.
They were also handing out free pizza and pop.
Needless to say, I wanted a few slices – but I figured it would be polite if I engaged them in conversation before waltzing off with some of the free food and drink they’d brought.
So I sparked up a conversation with one of the recruiters, and he told me about the company. I’m going to call this recruiter Vlad.
I ended up gently steering the conversation towards code review, and I asked my inevitable question:
“So, do you guys do code review?”
I felt like a dentist asking a patient if he’s been flossing. Vlad waffled a bit, but the general impression was:
“Not as much as we should. We don’t have a prescribed workflow. It’d be hard to persuade all of the teams to do it.”
And then we started talking about code review in general. It turns out that Vlad had worked in a few companies where they’d done code review, and he always felt a little short changed. He said something along the lines of:
“I never felt compelled to do reviews. They just sort of happened…and I did it, and it felt like…unrecognized effort. I mean, what’s the incentive? Do you know what I mean? There’s incentive for the software, but I’m talking incentive for me. And some people did really lousy reviews…but my reviews were treated the same as theirs. I didn’t get recognized, and didn’t get rewarded if I did a good review. So it was hard for me to do them. I want to be recognized for my good reviews, for my good contributions.”
I wish I’d had a tape-recorder running so I could have gotten Vlad’s exact words. But that’s what I remember him saying.
Feedback and Recognition
Maybe instead of trying to game-ulize code review, I can instead hear what Vlad is saying and work off of that.
With the code review that Vlad participated in, all of the feedback went to the code author, and none went to the reviewers. And the reviewers are the ones who are doing all of the heavy lifting! As a reviewer, Vlad also wants feedback, and recognition for code review done well.
There’s a company in Toronto that specializes in feedback like this. They’re one of the major players in the Toronto start-up scene, and have built a pretty sweet suite of tools to facilitate quick and easy feedback/recognition.
The company is called Rypple. And maybe that’s the name of the application, too. (checks website) Yeah, it’s both.
So Rypple has this feature called Kudos that let’s people publicly acknowledge the good work of their team.
Normally, I don’t pimp companies. And it upsets me when people comment on my blog, and their sub-text is to try to sell their product or service. However, I think this video is relevant, so I’m posting their demo video so you can see how Kudos work:
Click here if you can’t see the video.
The Idea
So Rypple’s idea is to have a feed that the team subscribes to, and publicly display things like Kudos. The badges for the Kudos are also limited in how many you can give per week, so they’re a valuable commodity that can’t just be handed out all over the place. Cool idea.
So there’s one approach – use a service like Rypple to give your reviewers better feedback and recognition.
Or maybe we could build an extension for Review Board that does something similar, and more oriented around code review.
It’s not oriented like a game, like I had originally envisioned. But somehow, I think this idea has more meaning and traction than just “adding points”.
More on this idea in a few days. But please, comment if you have any thoughts or ideas to add.
Hey Mike,
My name’s Tiho and I’m a developer at Rypple. Thanks for the shout out.
You’re right when it comes to code reviews, reviewers not getting feedback and recognition for a job well done. I’ve had some great code reviews and some were awful. The awful code reviews were the ones where people used the wrong tone and made it personal – that, of course, is never productive. Developers usually have strong egos so it’s important to critique ideas and not implementors – and to emphasize the difference. Unless great process elements are in place and people understand this tendency for critiques to be interpreted as personal attacks, code reviews become antagonistic processes. It’s easy to see why Vlad didn’t feel compelled to do them. On top of that, if code reviews take a significant portion of your time and you don’t get recognized for that, it’s hard to provide the right incentive.
A quick way we deal with recognition for code reviews is to make shout outs to people in morning stand-ups who were especially helpful the day before. And yes, we do send each other Kudos (Thanks) to let others at the company know someone’s help was crucial.
I’d like to hear more about your recognition idea for giving incentives for code reviews.
Tiho
My biggest beef with doing code reviews is when I put my heart and soul into doing code reviews and then people completely ignore my feedback, with no response and not taking my feedback into account! Well what was the point then? I guess one way to help with that would be to increase the enforcement on getting a “Ship It!” before committing to the trunk.
@Tihomir:
> Developers usually have strong egos so it’s important to critique ideas and not implementors
To add further complication, for highly-distributed development teams, there are *cultural* factors to consider as well. Some cultures might perceive code review as degrading, or as an insult.
Criticism and feedback can be complicated. 😉
> I’d like to hear more about your recognition idea for giving incentives for code reviews.
I’m solidifying my ideas and writing them up – just give me a few days.
In the meantime – I have a question for you. I would assume you’d consider Rypple to be an expert in feedback/constructive criticism, and the various social factors that come into play with it. I’m curious: how do you deal with very passive criticism?
For example: say I’m on a team with two other developers, and both of them have been getting all sorts of Kudos from our team lead. But I haven’t gotten any Kudos at all. While one remedy would be for me to step up my game, what’s stopping me from just silently sulking about my lack of kudos instead? Is this something you’ve come across?
Thanks,
-Mike
@Tara:
Well, hopefully, once I finish shaping my ideas, there’ll be a mechanism for getting feedback/recognition for your code reviews.
Enforcing the “ship-it” before committing…that’s not really something Review Board can do. I mean, we can make it so that you can’t mark a review request as “submitted” if it hasn’t gotten a ship-it, but we can’t as yet control the repositories. Review Board will not stop you from committing un-reviewed code. I don’t think it ever will, either. I think it’s a team/developer discipline thing. Gotta build up a code review culture.
-Mike
Mike, I would not assume that just because your team lead hasn’t given you any Kudos that he/she does not appreciate your work. In fact, in some case, she/he may feel you don’t need positive encouragement because you’re doing a fine job and/or because you’re confident enough.
Not trying to defend your team lead, but just hoping you don’t jump to negative conclusions prematurely. I’d suggest raising it in a one on one setting. It may be uncomfortable but it’s better than coming to wrong conclusions in isolation and then having that affect your performance – it might become a self-fulfilling prophecy in that if you think your team lead does not appreciate you your performance will deteriorate and he/she will really not appreciate your efforts.
Our hope is to prevent this from happening by building Rypple around solid coaching practices we’ve observed best managers do.
Our Coach product enables team leads (or coaches in general) and their reports to organize their thoughts, collaborate and meet in a one on one setting to discuss outcomes. As a team lead using Rypple, you’d clearly see that one of your reports never got any Kudos while the other two got plenty. You’d be prompted to rectify that. Also, at the end of a self-defined period, you’d be reminded to enter notes (including recognition, positives criticism, and actions) into Rypple and share that with the person you coach (again hopefully in a 1:1 settings but some people meet virtually as well). This way you are periodically reminded to give feedback to people you coach/manage.
I hope you have that discussion with your team lead. Let me know if I can help.
Tiho
@Tihomir:
Whoops! Sorry – I think I really misrepresented myself.
I’m not *actually* on a team that uses Rypple – that was an example. I’m still a jobless graduate student. I should have made it more clear that this question was hypothetical. 🙂 I’m just curious how you’d deal with that situation.
But you’ve answered my question anyways, so thanks!
-Mike
Praise does not need to be public, so a kudos system might be best adapted to private congratulations, with some limited public kudos. As Mike said, it could affect someone if they never get kudos, even though they are a good employee (just kindof average, not excellent in any area). But I’m speculating here.