How to Run a Code/Peer Review 101

Filed in archive Application Development on November 5, 2005

During my career I've had to facilitate peer reviews with developers on my teams. Each time I've been surprised when a new member on the team would not know how the process would play out. In my humble opinion (IMHO) most development teams simply do not perform peer reviews and I think it is a total shame. These sessions are valuable for a number of different reasons:

• Junior developers learn from their own mistakes and a mini mentoring sessions can take place during the review


• This becomes a time when everyone can validate that basic coding standards are being followed (I'm not too strict on this but like to see that things aren't completely out of control)


• Questions can be answered about things that were not fully covered in the technical specification or that have turned out to be incorrect


• A form of team building or ice breaking takes place during a peer reviews that I do not think happens in any other social situations

Before a manager or team leader calls a group of developers into a room to and starts a peer review I think a few things should be done.

• Ask for one person to volunteer as the primary developer who will present at the review


• Talk with the developer and pick a specific piece of functionality that will be reviewed


• Tell the developer that two or three days before the review to distribute the code to be review to all the other team members that will be present.


• Ask the team members that will be attending to review the code and be prepared to ask at least one question about it

During the review make it very clear who the facilitator of the review is and that this person needs to control the flow of the meeting. This person should not be the developer presenting the code. Developers tend to get very passionate about things and that should not be the point of the meeting. Issues should be recorded and it should be made clear that they will be addressed at a later date. A printed version of the code being reviewed should be available to each person attending. Also, I find it useful for the developer presenting to use an overhead projector to step through the code. It is also very insightful for everyone if the developer presenting can walk through the code in a debugger. However, very often this is not feasible.

Be clear at the start of every peer review that the point of the session is to educate everyone present and that it is not a disciplinary session. The facilitator of the session should encourage and protect that developer that is presenting. The last thing a team wants to do is ostracize the developer presenting. This should be a fun session where people let their hair down and have an open mind. If the developer presenting is treated shabbily by the team future reviews may not work. If the sessions go negative they can have a very bad influence on your team but when they work it adds a dynamic to a project that is hard to duplicate otherwise.