that it was preferable to limit the advance work and delay written comments until a couple of days before the meeting to avoid reviewers influencing one another too much. Experience showed that such concern was misplaced; interaction among reviewers, before, during, and after the meeting, is one of the most effective aspects of the process.

Prior to the meeting, the reviewers provide their comments on the review page (the shared document); the code author then responds just below the comments on the same page. The benefit of this approach is that it saves time. Before we systematized it we spent considerable time in the meeting on noncontroversial issues; in fact, our experience suggests that with a competent group of developers most comments and criticisms are readily accepted by the code’s author. We should instead be spending our meeting time on the remaining points of disagreement. Otherwise we end up replaying the typical company board meeting as described in the opening chapter of C. Northcote Parkinson’s Parkinson’s Law. ⁴ (The two items on the agenda are the color of bicycles for the mail messengers and whether to build a nuclear plant. Everyone has an opinion on colors, so the first item takes 59 minutes, ending with the decision to form a committee; the next decision is taken in one minute, with a resolution to let the CEO handle the matter.) Unlike this pattern, the verbal exchange in an effective review should target the issues that truly warrant discussion.

For an example of a document produced before and during one of our code reviews, see dev.eiffel.com/ reviews/ 2008-02-sample.html, which gives a good idea of the process. For a more complete picture of what actually goes on during the meeting, also see the discussion extract from the chat window (names blocked out) in Figure 2.

scope of Review

The standard review-page structure consists of nine sections dividing the set of software characteristics under review:

˲ Choice of abstractions;

˲ Other aspects of API design;

˲ Other aspects of architecture (such

as choice of client links and inheritance hierarchies);

˲ Contracts;

˲ Implementation, particularly the choice of data structures and algorithms;

˲ Programming style;

˲Comments and documentation (including indexing/note clauses);

˲ Global comments; and

˲Adherence to official coding practices.

The order of these sections goes from more high-level to more imple-mentation-oriented. Note that the first four concern not just code but architecture and design as well:

˲ The choice of abstractions is the key issue of object-oriented design. Developers discuss whether a certain class is really justified or should have its functionalities merged with another’s, or, conversely, whether an important potential class has been missed;

˲ API design is essential to the usability of software elements by other elements and as a consequence to reusability. We enforce systematic API design conventions through strong emphasis on consistency across the entire code base. This aspect of software development is particularly suitable for review; and

˲ Other architectural issues are also essential to good object-oriented development; the review process is useful (during both the preparatory phase and the meeting itself) to address such questions as whether a class should inherit from another or just be its client.

Algorithm design (the fifth section in the list) is another good candidate for discussion during the meeting.

In our process, the lower-level sections—programming style, comments and documentation, global comments, and coding practices—are increasingly handled before the review meeting (in writing), enabling us to devote the meeting itself to the deeper, more delicate issues.

The division into nine sections and the distribution of work through written comments prior to the meeting and in-meeting verbal discussions yield the following benefits:

˲ The group saves time; precious personal interaction time is reserved only for the topics that really need it;

˲ Discussing issues in writing makes

it possible to include more thoughtful comments; participants can take care to express their observations, including criticism of design and implementation decisions and corresponding responses, more easily than through a verbal conversation alone;

˲ The written support allows editing and revision;

˲ A record is produced. Indeed, the review needs no secretary or the tedious process of writing minutes. The review page (in its final stage after joint editing) is the minutes;

˲ Verbal discussion time is much more interesting since it addresses issues of substance. The dirty secret of traditional code reviews is that most of the proceedings are boring to most participants, each of whom is typically interested in only a subset of all the items discussed. With an electronic meeting each participant resolves issues of specific concern in advance and in writing; the verbal discussion is devoted to the controversial and hence most interesting stuff; and

˲ In a group with contentious personalities, one may expect that expressing comments in writing will also help defuse tension. (I say “may expect” because I don’t know this from experience; our developer group is not contentious.)

Through our electronic meetings, not just code reviews, another example has emerged of how constraints can be turned into benefits. Individually, most people (apart from, say, piano players) are most effective when doing one thing at a time, but collectively a group of humans is pretty good at multiplexing. When was the last time you spent an hour-long meeting willingly focused throughout on whatever issue was under discussion at the moment? Even the most attentive participants, disciplined to not let their minds wander off topic, react at different speeds; you may be thinking deeply about some previous item, while the agenda has moved on; you may be ahead of the game; or you may have something to say that complements the comments of the current speaker but do not want to interrupt her. This requires multi-threading, but a traditional meeting is sequential. In our code reviews and other meetings we have learned to practice a kind of organic multithread-