Code Reviews In The Real-World
When I first wrote about professional reviews as a mentoring platform, some people responded with the question: what’s wrong with peer reviews anyway? Why do we need a person specializing in code and design reviews instead of assigning this task to peer developers within the development team?
As I explained in previous posts (and as you will be able to read in my upcoming book) there are actually many reasons for seeking a better approach to code and design reviews. But three recent articles I came across might shed a new light on this question.
A couple of days ago Bruce Eckel wrote a short article claiming that code and design reviews are not as popular as one might think. In fact, he compares their questionable popularity to that of unit testing a few years back.
“Economics are an important reality in software projects. You have limited resources (which includes time), and your success or failure depends on how you allocate those resources. Which brings us back to the question of "if reviews are so useful and cost-effective, why don’t software organizations do more of them?”
In a post from two months ago, Ed Gibbs writes that although he planned to start conducting code reviews two years ago, his team is just starting this process:
“Next suggestion would be informal code reviews. We talked about this, sort of buddy type reviews, but we really never implemented them. After two years we’re just now implementing code reviews, and I can see why we should have done it so much sooner.”
And then there’s Brian Slesinsky’s article. Apart from the fact that Brian prefers pair programming (an issue which deserves a post of its own), his article includes many truths about peer reviews in the real-world. Brian describes the overhead of peer reviews, how they interrupt developers in their daily work, and what emotional effect they have on developers.
“The code review process is bad for concentration, both for the developer and the reviewer. Because there’s usually a delay waiting for code review, many developers work on multiple things at once and switch between them at submit time.”
In a conversation I had with one of the industry’s leading consultants a couple of months ago, she praised peer reviews and called it the most effective review approach. When I then asked her in how many organizations did she see systematic peer reviews being implemented, she answered: “only a handful”.
These three articles and single conversation are far from being a real statistical sample. But I believe they do represent the common approach regarding reviews. Everyone knows that code and design reviews are good, but most organizations don’t do them (at least not systematically). Even when an organization does have systematic peer reviews, most developers don’t like them. They feel peer reviews is a burden both to the developer writing the code and to the one reviewing it. The result: most of the code written "out there" is not being reviewed.
Maybe the reason peer reviews are not as popular as one might conclude from reading the literature is, as Bruce Eckel suggests, lack of experience. But maybe the reason is some inherent flaw of peer reviews.
Maybe, as Brian says, systematic peer reviews burresult in heavy context switching, which creates inadequate conditions for developers to work in. Maybe this alone is a good enough reason to start looking for a different approach which would have less impact on the daily routine of developers. And maybe this new approach might also have an additional benefit, which peer reviews don’t have even when they are implemented.
Maybe this new approach is already in reach.
July 12th, 2006 at 9:59 am
What about the parallels between reviewing and testing? If reviewing causes context switches, wouldn’t testing do the same thing? This has been typically solved by having a separate test team.
What would be the effect of having a separate review team?
I seem to recall reading that Dave Cutler reviewed checkins to the NT source base.