The "What's not to like about this code?" game

(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.

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: