The end of the year is swiftly approaching, and as the budget cycle is coming to a close, the work piles up quickly. I have had a staff of three from January through August, and with the piling work, we have had to triple in size. A staff of nine is very different to manage compared to a staff of three. There are many things to wrangle during ramp-up: a new corporate culture, new policies, new development environment, new standards, new team members. One of the tools in the technology manager’s arsenal is the peer review.
The CodingHorror web site outlines why they think software development departments should perform code reviews in their article called “Code Reviews: Just Do It.” Jared Richardson also describes the value of peer code reviews on his blog. The basic reasons for implementing code reviews are obvious: reduced bugs, reduced rework, cross training, quicker ramp-up time, sharing of ideas, developer growth, mentorship opportunities, and team building.
Karl E. Wiegers has written a great article called “Seven Truths About Peer Reviews” available on processimpact.com that outlines a number of different methods to conduct your peer code review. Some of the peer review methods methods he describes are inspection (both Fagan Method and Gilb/Graham Method), team reviews, walkthroughs, pair programming, peer deskchecks, and passarounds. It’s a good read, and you should take a look.
Peer reviews do not need to be long, drawn out, complicated processes. Jason Cohen describes some best practices for peer code review on his web site, SmartBear.com. He has written a great looking book called “Best Kept Secrets of Peer Code Review” that you can order free on his site. He recommends only reviewing code for five to ten minutes at a time, to keep everyone sharp, focused, and on point.
You should definitely walk into your peer code review with a plan in mind. Here is a Code Review Checklist for Macadamian that will help you organize your approach and keep you focused.
Finally, peer code reviews can be rough on the ego of the developer. Here are “Ten Commandments of Ego-less Programming” based on Jerry Weinberg’s book , The Psychology of Computer Programming, from 1971. This article describes how peer code reviews result in shorter project completion times, lower defect counts, and how developers had to set their egos aside to make it happen.
I am sure that code reviews will be good for my team, our projects, and our clients. The hurdle is making them part of our development routine. What do you think of code reviews? Do you use them in your technology department? What results have you seen? Leave me feedback and let me know.