ing: Someone may be talking; someone else may be writing a comment in
the chat window (such as a program
extract that illustrates a point under
discussion or a qualification of what
is being said); others may be updating
the common document; and yet someone else may be preparing next week’s
document or a Wiki page at dev.eiffel.
com. The dynamics of such meetings
are amazing to behold, with threads
progressing in parallel while everyone
remains on target and alert.
Team distribution is a fact of life
in today’s software development and
can be a great opportunity, as well as a
challenge, to improve the engineering
of software. I also practice distributed
team development in an academic environment. ETH Zurich offers a course
called Distributed and Outsourced
Software Engineering, or DOSE, specifically devoted to the issues and techniques of distributed development. In
fall 2007, it meant, for the first time,
a cooperative project involving several universities. This was a trial run,
and we are now expanding the experience; for details see se.ethz.ch/dose/.
Participation is open to any interested
university worldwide; the goal is to let
students discover and confront the
challenges of distributed development
in the controlled environment of a university course.
Not all of our practice may be transposable to other contexts. The core
EiffelStudio group includes only about
10 people who know each other well
and have worked together for several
years; we developed these techniques
together, learning from our mistakes
and benefiting from recent advances
in the communication technology discussed here. But even if all the details of
our experience cannot be generalized,
distributed software development, and
with it distributed reviews, are the way
of the future. Even more so considering that the supporting technology is
still in its infancy. As recently as 2006,
most of the communication tools we
use today did not exist; in 2003 none
of them did. It is ironic now to recall
the talks I heard over the years about
“computer-supported cooperative
work”—fascinating but remote from
anything my colleagues or I could use.
Suddenly comes the Web, VoIP solutions for common folk, shared editing
interaction among
reviewers, before,
during, and after
the meeting, has
turned out to be
one of the most
effective aspects
of the process.
tools, and new commercial offerings,
and the gates to globalized cooperative
development open without fanfare.
The tools are still fragile; we waste
too much time on meta communication (“Can you hear me?,” “Did Peter
just disconnect?,” “Bill, mute your
microphone.”), calls are cut off, and
we lack a really good equivalent of a
shared whiteboard. Other aspects of
the process also still need improvement; for example, how can we make
our review results seamlessly available
as part of the EiffelStudio open-source
development site based on Wiki pages? All this will be corrected in the next
few years. I also hope that courses like
DOSE and other academic efforts will
enable the commercial world to understand better what makes collaborative
development succeed or fail.
This is not just an academic issue.
Eiffel Software’s experience in collaborative development—whereby
each meeting brings new insight—
suggests that something fundamental
has changed, mostly for the better, in
the software-development process. As
for code reviews, I do not expect ever
again to get stuck for three hours in
a windowless room with a half dozen
other programmers poring over boring
printouts.
acknowledgment
I am grateful to the EiffelStudio developers for their creativity and the team
spirit that enabled them collectively to
uncover and apply the techniques discussed here.
References
1. Fagan, M.E. Design and code inspections to reduce
errors in program development. IBM Systems Journal
15, 3 (1976), 182–211; www.research.ibm.com/journal/
sj/153/ibmsj1503C.pdf.
2. Ghezzi, C., Jazayeri, M., and Mandrioli, D.
Fundamentals of Software Engineering, Second
Edition. Prentice Hall, Upper Saddle River, NJ, 2002.
3. Meyer, B. and Piccioni, M. The allure and risks of
a deployable software engineering project. In
Proceedings of the 21st IEEE-CS Conference
on Software Engineering Education and Training
(Charleston, SC, Apr. 2008).
4. Parkinson, C. Northcote. Parkinson’s Law: The Pursuit
of Progress. John Murray, London, 1958.
Bertrand Meyer ( Bertrand.Meyer@inf.ethz.ch) is a
professor of software engineering at ETH Zurich, the
Swiss Federal Institute of Technology, and chief architect
of Eiffel Software, Santa Barbara, CA.
