(http://us2.campaign-archive2.com/?u=80ca60ec48ef77dfaa1f38943&id=acc77a0fb2&e=da9067a70f)
If you find yourself around people who doubt the value of code reviews, then this game can help you get much of the benefit while avoiding some of the stress. It does require, however, at least one person who won't feel emotionally crushed by having eir code criticised. If you have code written by people no longer with the team, then so much the better.
- Gather the team in a room.
- Schedule 1-2 hours.
- Have a whiteboard or flipchart handy and nominate someone to take notes. It works best if the note-taker doesn't participate in the game, although experienced players can do both more effectively.
Project some code onto the wall or a screen. Ask the team "What's not to like about this code?". I pick this form of the question very carefully, because I want to focus on problems and not solutions nor potential improvements. People in the room shout out answer to the question and the note-taker writes them down. If someone shouts out a solution/improvement, then the facilitator replies with some variation on "why do you want to change the code this way?" or "what problem in the code does that solve?" The facilitator has the tough job of relentlessly finding the underlying problem/issue/deficiency that the programmer wants to solve/address/ameliorate.
We never change the code when we play this game. (All right: after you've become very experienced players, you can break this rule, but novices should never change the code.) Instead, we do a number of useful things:
- We practise articulating what we don't like.
- We learn more about each other's standards and disciplines.
- We learn more about what each other is willing to tolerate.
- We practise empathising by putting ourselves in the shoes of the person who wrote the code.