contributed articles

Doi: 10.1145/1378727.1378744

New collaboration tools allow geographically
distributed software-development teams to
boost the venerable concept of code review.
BY BeRtRanD me YeR
Design and
code Reviews
in the age of
the internet
CODE REVIEWS ARE A standard practice of software
engineering. Rather, they are a standard practice
of the software engineering literature. Widely
recommended, certainly, but how widely practiced,
i am not sure.

in the development of EiffelStudio, a large integrated development environment (iDE), Eiffel Software has begun to apply code reviews with the added twist that the developers work on three continents. A distributed setup is increasingly common in the i T industry, though not always in such an extreme form. it naturally leads to distributing the reviews as well. This decision forced our development group to depart from the standard scheme described in the literature² and take a fresh look at the concept. Some of what initially appeared as constraints—

the impossibility of ever having all the people involved at the same time in the same room—turned out in practice to be beneficial, encouraging us to emphasize the written medium over verbal discussion, conduct much of the process prior to the actual review meeting, and take advantage of communication tools to allow several threads of discussion to proceed in parallel during the meeting itself. We also expanded our reviews, beyond just code, to cover design and specification as well. The process relies on modern, widely available communication and collaboration tools, most introduced over the past few years with considerable room for improvement. This article describes some of the lessons our team has learned with the hope they will be useful to other teams practicing distributed development.

Michael Fagan of IBM introduced the concept of “code inspections,” his original name, in a 1976 article. ¹ Whether inspection or review, the idea is to examine some element of code in a meeting typically attended by perhaps eight people, with the aim of finding flaws or elements that should be improved. This is the meeting’s only goal. It is not intended to assess the code’s author, though in practice it is not easy to avoid doing so, especially when the manager is present; neither should it serve to correct deficiencies, only to uncover them.

The code and any associated elements are circulated a few days in advance. The meeting, which typically takes a few hours, includes the author, other developers competent to assess the code, a meeting chair (not the manager) who moderates the discussion, and a secretary who records it, producing a report with specific recommendations. Some time later, the author responds to the report by describing whether and how the recommendations have been carried out.

This is the basic idea behind a traditional code review and is often criticized on a variety of grounds. Advocates of extreme programming point