<< MuNDDoS Research Group >>

More than a decade ago, seeking lower costs and access to skilled resources, many organizations began to experiment with remotely located software development facilities and with outsourcing. Several factors have accelerated this trend:
     - the need to capitalize on the global resource pool to successfully and cost-competitively use scarce resources, wherever located;
     - the business advantages of proximity to the market, including knowledge of customers and local conditions, as well as the good will engendered by local investment;
     - the quick formation of virtual corporations and virtual teams to exploit market opportunities;
     - severe pressure to improve time-tomarket by using time zone differences in "round-the-clock" development; and
     - the need for flexibility to capitalize on merger and acquisition opportunities wherever they present themselves.

As a result, software development is increasingly a multisite, multicultural, globally distributed undertaking. Engineers, managers, and executives face numerous, formidable challenges on many levels, from the technical to the social and cultural. Is working at a distance really such a problem? Nearly everyone with GSD experience, it seems, has anecdotes illustrating difficulties and misunderstandings. While these stories are compelling, they do not give us a clear picture of its cumulative effects. However, we have strong evidence, based both on statistical modeling of development interval and on survey results, that multisite development tasks take much longer than comparable colocated tasks and that communication and coordination play major roles in this delay.

While we focus primarily on the problems of GSD, we should not neglect the potential benefits of geographic dispersion. For example, if an organization can manage daily handoffs of work between remote sites and focus attention around the clock on critical-path tasks, it is possible to take advantage of widely dispersed time zones. We could theoretically extend the productive hours of the day from the current 8- to 10- hour norm to somewhere near the limit of 24. This is perhaps a distant goal as a general model for development, but occasional benefits-for example, accelerated problem investigation or a distributed daily test-andfix cycle-are possible.

Moreover, we probably think of "distributed" work in much too limited a way. Distances need not be global to be important. In fact, being in another building or on a different floor of the same building, or even at the other end of a long corridor, severely reduces communication. Solutions that help globally distributed colleagues work together more effectively will often help those in the same zip code as well.