Continuous Coordination:
A New Paradigm for Collaborative Software Engineering Tools


André van der Hoek, David Redmiles, Paul Dourish
Anita Sarma, Roberto Silva Filho, Cleidson de Souza
Department of Informatics
School of Information and Computer Science
University of California, Irvine
Irvine, CA 92697-3425 USA
{andre, redmiles, jpd, asarma, rsilvafi, cdesouza}@ics.uci.edu


Abstract

Collaborative software engineering tools that have
been developed and used to date exhibit a fundamental
paradox: they are meant to support the collaborative ac-
tivity of software development, but cause individuals and
groups to work independently from one another. The un-
derlying issue is that existing tools discretize time and
tasks in concrete but isolated process steps. This ap-
proach is fundamentally flawed in assuming that human
activity can be codified and that periodic resynchroniza-
tion of tasks is an easy step. We propose a new approach
to supporting collaborative work called continuous coor-
dination. The underlying principle is that humans must
not and cannot have their method of collaboration dic-
tated, but should be supported flexibly with both the tools
and the information to coordinate themselves and col-
laborate in their activities as they see fit. In this paper, we
define the concept of continuous collaboration, introduce
our work to date in building some example tools that sup-
port the continuous coordination paradigm, and set out a
further research agenda to be pursued.

1. Introduction

Collaboration is at the heart of software development.
Most software is developed by a group of people rather
than an individual. This means that software engineering
environments and processes must support the coordina-
tion of the activities that individuals carry out within the
overall objectives of the group at large. Within the soft-
ware engineering community, the response has been a
flurry of research and development that has resulted in the
availability of a host of formal software process lan-
guages and environments. These languages and environ-
ments aim to help users in choosing their tasks, obtaining
prerequisite input from a set of relevant people and tools,
performing their tasks, and sending their output to another
(sometimes overlapping) set of relevant people and tools.
While this has certainly helped in advancing the ability of
individuals to collaborate in groups, these approaches are
built on a fundamental paradox: to collaborate, individu-
als work completely independently from each other and
are isolated by the environment that supports their day-to-
day activities.
Within the computer-supported cooperative work
community, the response has been virtually the opposite
rather than constraining and guiding a user in their tasks,
the focus is on informally raising awareness by informing
users of ongoing, parallel activities so they can interpret
this information and self-coordinate amongst each other.
While this has lead to novel tools and approaches, there is
an issue of scalability and cognitive overload: users can
only absorb and meaningfully interpret limited amounts
of typically contextualized information.
In this paper, we introduce and explore an alternative
approach: continuous coordination. Continuous coordina-
tion blends the best aspects of the more formal, process-
oriented approach with those of the more informal,
awareness-based approach. In doing so, continuous coor-
dination blends processes to guide users in their day-to-
day high-level activities with extensive information shar-
ing and presentation to inform users of relevant, parallel
ongoing activities. Through this blending, users become
aware of the context in which they perform their work,
can interpret their context, and take action accordingly.
This allows users to self-coordinate within the overall
process to avoid situations in which their activities
threaten to obstruct or interfere with activities of others,
or simply to better organize and order respective tasks.

2. Motivating Example

To better understand why, when, and how software
developers coordinate their work, we conducted an eight-
week field study of existing software development prac-

tices at NASA/Ames Research Center [1,2]. In particular,
we studied a software team developing a suite of tools to
help air traffic controllers manage the increasingly com-
plex air traffic flows at large airports. The team is com-
posed of 25 co-located developers, who design, test,
document, and maintain the tools. Like most professional
software teams, they make use of an advanced configura-
tion management system, which they use to periodically
check out and check in chunks of code, as well as to co-
ordinate their parallel work. However, the configuration
management system tells only part of the story. Our field
study produced two important observations:
x While having at their disposal a state-of-the-art con-
figuration management system to coordinate their ac-
tivities, developers mostly relied on an informal
mechanism, e-mail, to inform each other about those
activities. Before a developer checks in changes, for
instance, it is customary to send an e-mail notifying
the whole group of not just the imminent action, but
also of the effect it may have on the work of every-
body else.
x While developers stated in our interviews that the
combination of configuration management with e-
mail works fine for them, in reality we observed that
this is not the case. For example, when they get
closer to completing their changes, often they rush to
be the first to check in to avoid having to be the per-
son who has to merge and/or retest. As another ex-
ample, they often do not wait until they have finished
their work, but instead try to minimize the possibility
of conflicting changes by checking in partially com-
pleted work.
These examples highlight a mismatch between the col-
laboration model supported by the configuration man-
agement system and the actual collaboration needs of the
developers. While the technology embodies a model of
collaborative work designed to ensure team progress with
a minimum of coordination problems, in practice we see
that these formal mechanisms are accompanied by a set of
less formal communicative practices which help to set the
formal work in context. In this particular case, the isola-
tion amongst the developers introduced by the CM system
is offset via primitive but somewhat disciplined use of e-
mail.
Our study is not unique in making these observations.
Time and again it has been demonstrated that software
engineering tools fail in their attempts to codify human
activity (e.g., [3, 4, 5]). They limit the dimensions of hu-
man activity and creativity, and therefore are unsuccessful
in providing adequate support for effective and flexible
collaboration. The resulting problems are dramatic: much
time and effort is wasted in resolving conflicting changes;
salient faults are introduced as a result of parallel but un-
detected incompatible changes; and the team as a whole
has little intellectual and conceptual integrity. Overall, the
software development process remains ineffective and
instills a false sense of security in its ability to manage the
collaborative effort.

3. Formal Coordination

Many software engineering tools that support coordi-
nation and collaboration rely on a formal, process-based
approach [6]. A process model, either implicitly or explic-
itly defined by the tool, splits work into multiple, inde-
pendent tasks that are periodically resynchronized. This
approach, illustrated in row 1 of Table 1, can be charac-
terized as inherently group-centric: it makes the group as
a whole the important entity by providing a scalable, pre-
dictable, and dependable solution that promotes tight-
controlled coordination and insulates different activities
from each other. The canonical example is a configura-
tion management system: by checking out artifacts a de-
veloper is insulated from other activities and by checking
in any modified artifacts the developer resynchronizes
their work with the work of the group.
The formal, process-based approach, however, suffers
from two significant problems that make it a less-than-
effective solution when it comes to coordination and col-
laboration:
1. Formal processes can describe only part of the activ-
ity of software development (or any collaborative
task). No matter how formal and well-defined a proc-
ess may seem, there is always a set of informal prac-
tices by which individuals monitor and maintain the
process, keep it on track, recognize opportunities for
action and the necessity for intervention or deviation.
In other words, no process description will or can
ever be complete (e.g., [7]).
2. Even when a process description attains a relatively
high degree of detail and accuracy, the periodic re-
synchronization of activities remains a difficult and
error-prone task. In fact, it has been shown that when
more parties are involved, more conflicts arise and
more faults are introduced in the software at hand
(e.g., [8]).
There are solid theoretical foundations to back up
these observations (e.g., [9, 10]). What the theory indi-
cates is that the empirical phenomena observed are not
simply signs of poorly-designed processes or badly-
specified tools. Rather, these problems are inherent in any
tool that relies upon a formal encoding of collaborative
work. Any formal process is inevitably surrounded by a
set of informal practices by which the formal conditions
are negotiated and evaluated.