are across the code base, size of the change, and severity, the
effect of being distributed was no longer significant. They
hypothesize that large and/or multi-module changes are
both more time consuming and more likely to involve multiple sites. These changes require more people, which introduce delay. They conclude that distributed development
indirectly introduces delay due to correlated factors such as
team size and breadth of changes required.
Thanh et al.
19 examined the effect of distributed development on delay between communications and time to resolution of work items in IBM’s Jazz project, which was developed
at five globally distributed sites. While Kruskal–Wallis tests
showed a statistically significant difference in resolution
times for items that were more distributed, the Kendall Tau
correlations of time to resolution and time between comments with number of sites were extremely low (below 0.1
in both cases). This indicates that distributed collaboration
does not have a strong effect.
Herbsleb and Mockus12 formulate an empirical theory of
coordination in software engineering and test hypotheses
based on this theory. They precisely define software engineering as requiring a sequence of decisions associated with
a project. Each decision constrains the project and future
decisions in some way, until all choices have been made, and
the final product does or does not satisfy the requirements.
It is therefore important that only feasible decisions (those
which will lead to a project that does satisfy the requirements) be made. They present a coordination theory, and
develop testable hypotheses regarding productivity, measured as number of MRs resolved per unit time. They find
that (a) people who are assigned work from many sources
have lower productivity, and that (b) MRs that require work
in multiple modules have a longer cycle time than those
which require changes to just one.
Unlike the above papers, our study focuses on the effect
of distributed development on defect occurrence, rather than
on defect resolution time.
3. 2. effects on quality and productivity
Diomidis Spinellis examined the effect of distributed development on productivity, code style, and defect density in the
FreeBSD code base.
23 He measured the geographical distance between developers, the number of defects per source
file, as well as productivity in terms of number of lines committed per month. A correlation analysis showed that there
is little, if any, relationship between geographic distance of
developers and productivity and defect density. It should be
noted that this is a study of open source software which is, by
its very nature, distributed and has a very different process
model from commercial software.
Cusick and Prasad5 examined the practices used by Wolters
Kluwer Corporate Legal Services when outsourcing software
development tasks and present their model for deciding if a
project is offshorable and how to manage it effectively. Their
strategies include keeping communication channels open,
using consistent development environments and machine
configurations, bringing offshore project leads onsite for
meetings, developing and using necessary infrastructure and
tools, and managing where the control and domain expertise
lies. They also point out that there are some drawbacks that
are difficult to overcome and should be expected such as the
need for more documentation, more planning for meetings,
higher levels of management overhead, and cultural differences. This work was based on an offshoring relationship
with a separate vendor and not collaboration between two
entities within the same company. We expect that the challenges faced in distributed development may differ based on
the type of relationship between distributed sites.
Ramasubbu and Balan21 examined the relationship
between the dispersion (a measure of geographic dispersion)
of a project and its development productivity and
conformance quality. They gathered information from 42 projects
over 2 years and found that projects that had more dispersion also had lower levels of productivity and conformance
quality, though the effects were strongly mitigated through
quality management approaches. In their study, productivity and quality were measured on a project basis between
different projects, while our study examines characteristics
of components within one large software project, which
arguably provides better control over possibly confounding
Our study examines distributed development in the context of one commercial entity, which differs greatly from
both open source projects and outsourcing relationships.
3. 3. Issues and solutions
In his paper on global software teams,
3 Carmel categorizes
project risk factors into four categories that act as centrifugal forces that pull global projects apart. These are
• Loss of communication richness
• Coordination breakdowns
• Geographic dispersion
• Cultural differences
In 2001, Battin et al.
1 discussed the challenges and their
solutions relative to each of Carmel’s categories in a large
scale project implementing the 3G Trial (Third Generation
Cellular System) at Motorola. By addressing these challenges in this project, they found that globally distributed
software development did not increase defect density, and
in fact, had lower defect density than the industrial average. Table 1 lists the various locations, the size of the code
developed at those locations, and their defect density. They
summarize the key actions necessary for success with global
development in order of importance:
• Use Liaisons
• Distribute entire things for entire life cycle
• Plan to accommodate time and distance
Carmel and Agarwal4 present three tactics for alleviating
distance in global software development, each with examples, possible solutions, and caveats:
• Reduce intensive collaboration.
• Reduce national and organizational cultural distance.
• Reduce temporal distance.