Making Software

Group Dynamics

So far we’ve been considering a lone developer reviewing code in isolation, but that’s almost never the entire process.

In fact, code review is one of the few activities developers do together. That in itself is an interesting argument for code review; everyone agrees that some level of interaction and collaboration is required to spread institutional knowledge, teach each other tricks, and solve particularly tricky problems.

Still, if wasting a single person’s time is expensive, it’s absolutely devastating to waste several people’s time. So let’s look at what the data tell us about how to ensure we’re not flushing entire person-days down the toilet.

Are Meetings Required?

When you think of a “code review,” you probably picture geeks huddled around a projector in a conference room criticizing a hapless developer as she walks through her code.

Besides putting the author in an unenviable position, this practice is also a potentially tremendous waste of time! Consider the traditional Formal Inspection, popularized by Michael Fagan [Fagan 1976], in which the focal point of the process is a two-hour meeting where four participants discuss the code.

Four people meeting for two hours is eight person-hours—an entire person-day of time! And that’s not counting the overhead for scheduling a conference room and waiting for stragglers to show. There’d better be a large benefit in future time saved to justify such a process. Or ice cream.

In Fagan’s theory the meeting is more than a ...