ers. This constraint is an example of a limitation that has turned out to be an advantage, forcing us to organize both the reviews and other meetings carefully and professionally.

Almost all of our development is done in Eiffel; one aspect of this choice that influences the review process is that Eiffel applies the “seamless development” principle, treating specification, design, and analysis as a continuum rather than as a sequence of separate steps (using, for example, first UML then a programming language); the Eiffel language serves as the common notation throughout. This has naturally caused the extension of the traditional review to design reviews, an extension that may also be desirable for teams using other development languages and a less-seamless process. Another aspect that influences EiffelStudio development is that, since IDEs are our business, the tool we produce is also the tool we use (following the “eat your own dog food” principle); we again feel the results would not fundamentally change for other kinds of software development.

Distributed reviews need support from communication and collaboration tools; we essentially rely on four such tools:

Voice communication similar to a conference call. We started with Skype but now use it only as a backup; our primary VoIP solution is a tool called X-Lite; such technology choices are subject to reassessment as the tools evolve;

Written communication. We retain Skype’s chat mechanism, so a window available to all participants is active throughout the review;

Google Docs for shared documents. Providing a primitive Microsoft-Word-like editing framework, Google Docs works on the Web so several people are able to update a given document at the same time. The means of resolving editing conflicts is fine-grained: most changes go through, even if someone else is simultaneously modifying the document; only if two people are changing the very same words does the tool reject the requests. While not perfect, Google Docs is an effective tool for collaborative editing, with the advantage that text can be pasted into and from Microsoft Word documents with approximate preservation of format;

What is remarkable
in the current
setup is that
we have not yet
identified a need
for specialized
review software,
being content
enough with
general-purpose
widely available
communication and
collaboration tools.

WebEx sharing tool for sharing screens. We find this tool (one of several, including Adobe Connect, on the market) especially useful for running a demo of, say, a new proposal for a graphical-user-interface idea or other element developers might have just put together on a workstation; and

Wiki pages. The EiffelStudio community, involving both Eiffel Software developers and numerous outside contributors, has a Wiki-based site (dev. eiffel.com) with hundreds of documentation and discussion pages. The site is useful, although the Wiki mechanism, with its traditional edit cycle— start editor, make changes, update page, refresh—is less convenient than Google Docs for working on a common document during a meeting.

Among the ideas described here, the choice of tools is the most likely candidate for quick obsolescence. The technology is evolving so quickly that a year or two from publication the solutions might be fairly different. What is remarkable in the current setup is that we have not yet identified a need for specialized review software, being content enough with general-purpose widely available communication and collaboration tools.

lessons learned

Here are some of the lessons we have learned from our distributed code review:

First, scripta manent, or “prefer the written word.” We have found that a review works much better when it is organized around a document. The team members produce a shared document (currently in Google Docs) ahead of the meeting and update it in real time during the meeting.

The “unit of review” is a class or sometimes a small number of closely related classes. A week ahead of the review, the software’s author, following a standard structure described in the following sections, prepares the shared document with links to the actual code.

One way this process differs from a traditional review is a practice we had not planned for when we first put reviews in place but which quickly imposed itself through experience: Most of the work is done offline before the meeting. Our original thinking was