We conclude that there is no discernible difference in
the measured metrics between distributed and collocated
We have presented an unexpected, but encouraging result: it
is possible to conduct in-house globalized distributed development without adversely impacting quality. It is certainly
important to understand why this occurred and how this
experience can be repeated in other projects and contexts.
To prime this future endeavor, we make some observations
concerning pertinent practices that have improved communication, coordination, team cohesion, etc., and reduced the
impact of differences in culture and business context. These
observations come from discussions with management as
well as senior and experienced developers.
Relationship between sites: Much of the work on distributed
development examines outsourcing relationships.
2, 6 Others
have looked at strategic partnerships between companies
or scenarios in which a foreign remote site was acquired.
These create situations where relationships are asymmetric.
Engineers at different sites may feel competitive or may for
other reasons be less likely to help each other. In our situation, all sites have existed and worked together on software
for many years. There is no threat that if one site performs better, the other will be shut down. The pay scale and benefits are
equivalent at all sites in the company.
cultural Barriers: In a study of distributed development
within Lucent at sites in Great Britain and Germany, Herbsleb
and Grinter10 found that significant national cultural barriers existed. These led to a lack of trust between sites and
misinterpreted actions due to lack of cultural context. This
problem was alleviated when a number of engineers (
liaisons) from one site visited another for an extended period
of time. Battin et al.
1 found that when people from different
sites spent time working together in close proximity, many
issues such as trust, perceived ability and delayed response
to communication requests were assuaged.
A similar strategy was used during the development of
Vista. Development occurred mostly in the United States
(predominantly in Redmond) and Hyderabad, India. In
the initial development phases, a number of engineers
and executives left Redmond to work at the Indian site.
Many of these people had 10+ years within Microsoft, and
understood the company’s development process. In addition, the majority of these employees were originally from
India, removing one key challenge from globally distributed work. These people acted as facilitators, information brokers, recommenders, and cultural liaisons4 and
had already garnered a high level of trust and confidence
from the engineers in the United States. Despite constituting only a small percent of the Indian workforce, they
helped to reduce both organizational and national cultural
communication: Communication is the single most referenced problem in globally distributed development. Face to
face meetings are difficult and rare and people are less likely
to communicate with others that they don’t know personally.
Distributed sites are also more likely to use asynchronous
92 communIcATIons of The Acm | auGust 2009 | Vol. 52 | no. 8
communication channels such as email which introduce a
task resolution delay.
The Vista developers made heavy use of synchronous communication daily. Employees took on the responsibility of staying at work late or arriving early for a status conference call on a
rotating basis, changing the site that needed to keep odd hours
every week. Keeping in close and frequent contact increases the
level of awareness and the feeling of “teamness.”
1, 4 This also
helps to convey status and resolve issues quickly before they
escalate. Engineers also regularly traveled between remote
sites during development for important meetings.
consistent Use of tools: Both Battin1 and Herbsleb and
Mockus11 cite the importance of the configuration management tools used. In the case of Motorola’s project, a single,
distributed configuration management tool was used with
great success. At Lucent, each site used their own management tools, which led to an initial phase of rapid development
at the cost of cumbersome integration work toward the end.
Microsoft employs the use of one configuration management
and builds system throughout all of its sites. Every engineer is
familiar with the same source code management tools, development environment, documentation method, defect tracking system, and integration process. The integration process
for code is incremental, allowing problems to surface early.
end to end ownership: Distributed ownership is a problem
with distributed development. When an entity fails, needs
testing, or requires a modification, it may not be clear who
is responsible for performing the task or assigning the work.
Battin mentions ownership of a component for the entire
life cycle as one of three critical strategies when distributing
development tasks. While binaries were committed to from
different sites during the implementation phase, Microsoft
practices strong code ownership. One developer is clearly “in
control” of a particular piece of code from design, through
implementation, and into testing and maintenance. Effort
is made to minimize the number of ownership changes.
common schedules: All of the development that we examined was part of one large software project. The project was
not made up of distributed modules that shipped separately.
Rather, Vista had a fixed release date for all parties and milestones were shared across all sites. Thus all engineers had
a strong interest in working together to accomplish their
tasks within common time frames.
organizational integration: Distributed sites in Microsoft do
not operate in organizational isolation. There is no top level
executive at India or China that all the engineers in those
locations report to. Rather, the organizational structure
spans geographical locations at low levels. It is not uncommon for engineers at multiple sites to have a common direct
manager. This, in turn, causes geographically dispersed
developers to be more integrated into the company and the
project. The manager can act as a facilitator between engineers who may not be familiar with one another and can
also spot problems due to poor coordination earlier than
in an organizational structure based purely on geography,
with less coupling between sites. Prior work has shown
that organizationally distributed development dramatically
affects the number of post-release defects.
18. This organizational integration across geographic boundaries reconciles