geographical, organizational, temporal, or stakeholder boundaries.
14 A scenario involving one company outsourcing work
to another will certainly differ from another, where multiple,
distributed teams work within the same company. A recent
special issue of IEEE Software focused on globally distributed
development, but the majority of the papers dealt with
offshoring relationships between separate companies and
outsourcing, which are likely very different from distributed sites within
the same company.
2, 5, 6 Even within a company, the development may or may not span organizational structure at different levels. Do geographical locations span the globe, including
multiple time zones, languages, and cultures or are they simply in different cities of the same state or nation?
We are interested in studying the effect of globally distributed software development within the same company,
because there are many issues involved in outsourcing that
are independent of geographical distribution (e.g. expertise
finding, different process, and an asymmetric relationship).
Our main motivation is to confirm or refute the notion that
global software development leads to more failures within
the context of our setting.
To our knowledge, this is the first large scale distributed
development study that considers distributed development
within an organization. This study augments the current
body of knowledge and differs from prior studies by making
the following contributions:
1. We examine distributed development at multiple levels of separation (building, campus, continent, etc.).
2. We examine a large scale software development effort,
composed of thousands of binaries and thousands
3. We examine complexity and maintenance characteristics of the distributed and collocated binaries to check
for inherent differences that might influence post-release quality.
4. Our study examines a project in which all sites involved
are part of the same company and have been using the
same process and tools for years.
There is a large body of theory describing the difficulties
inherent in distributed development. We summarize them
Communication suffers due to a lack of unplanned and informal meetings.
10 Engineers do not get to know each other on a
personal basis. Synchronous communication becomes less
common due to time zone and language barriers. Even when
communication is synchronous, the communication channels, such as conference calls or instant messaging, are less rich
than face to face and collocated group meetings. Developers
may take longer to solve problems because they lack the ability
to step into a neighboring office to ask for help. They may not
even know the correct person to contact at a remote site.
Coordination breakdowns occur due to this lack of communication and lower levels of group awareness.
1, 3 When managers must manage across large distances, it becomes more
difficult to stay aware of peoples’ task and how they are interrelated. Different sites often use different tools and processes
which can also make coordinating between sites difficult.
86 communIcATIons of The Acm | auGust 2009 | Vol. 52 | no. 8
Diversity in operating environments may cause management problems.
1 Often there are relationships between the
organization doing development and external entities such
as governments and third party vendors. In a geographically
dispersed project, these entities will be different based on
location (e.g., national policies on labor practices may differ
between the United States and India).
Distance can reduce team cohesion20 in groups collaborating remotely. Eating, sharing an office, or working late together
to meet a deadline, all contribute to a feeling of being part of a
team. These opportunities are diminished by distance.
Organizational and national cultural barriers may complicate globally distributed work.
4 Coworkers must be aware
of cultural differences in communication behaviors. One
example of a cultural difference within Microsoft became
apparent when a large company meeting was originally (and
unknowingly) planned on a major national holiday for one
of the sites involved.
Based on these prior observations and an examination of
the hurdles involved in globally distributed development we
expect that difficulties in communication and coordination
will lead to an increase in the number of failures in code produce by distributed teams over code from collocated teams.
We formulate our testable hypothesis formally.
H1: Binaries that are developed by teams of engineers that
are distributed will have more post-release failures than those
developed by collocated engineers.
We are also interested to see if the binaries that are distributed differ from their collocated counterparts in any
significant ways. It is possible that managers, aware of the
difficulties mentioned above, may choose to develop simpler,
less frequently changing, or less critical software in a distributed fashion. We therefore present our second hypothesis.
H2: Binaries that are distributed will be less complex, experience less code churn, and have fewer dependencies than
3. ReLATeD WoRK
There is a wealth of literature in the area of globally distributed software development. It has been the focus of multiple
special issues of IEEE Software, workshops at ICSE and the
International Conference on Global Software Engineering.
Here we survey important work in the area, including both
studies and theory of globally distributed work in software
There have been a number of experience reports for
globally distributed software development projects at various companies including Siemens,
10 and Philips.
3. 1. effects on bug resolution
In an empirical study of globally distributed software
11 Herbsleb and Mockus examined the time
to resolution of Modification Requests (MRs) in two departments of Lucent working on distinct network elements for
a telecommunication system. The average time needed to
complete a “single-site” MR was 5 days versus 12. 7 for “
distributed.” When controlling for other factors such as number of people working on an MR, how diffused the changes