The idea of an IT project team spread out over a wide geographical area is an old one. It became practical in the late ’70s and early ’80s, with the advent of hard disk drives─instead of punched cards, paper tape or magnetic tape─for source-code file storage, wide-area networking (including the Internet), modems, and personal workstations and computers. Early logistical problems, such as source-code control and configuration management, were largely solved or at least brought under control with a rapidly growing and evolving set of tools. That technology has continued to advance, particularly with the advent of a large number of Web-based tools to allow collaborative development anywhere an Internet connection and a browser are available.

In the years since then, organizations of all sizes and purposes have sought to develop software in a distributed fashion. The motivations have varied. Some have sought to coordinate the work of IT development shops in different corporate or governmental sites to bring more IT engineers to bear on a given project. Others have seen it as a telecommuting or quality-of-life issue, allowing developers to work from home. Yet others have sought to control IT costs by moving entire projects or portions thereof offshore to India, China and elsewhere.

With oil now exceeding $140 per barrel and the corresponding sharp rises in all transportation costs, the increased financial burden of getting engineers together in the same location, whether it’s driving to work or flying across the country, makes distributed development all the more attractive.

Whatever the motivation, the real problems with distributed development─which persist to this day─are the human ones, such as communications among engineers, conceptual unity of the system under development and personnel management.

It is a long-standing axiom in the software engineering world that the best software is written by a small number of talented developers working in proximity to one another. Why?

• They can easily interact and solve problems as a group.

• Each developer can readily ensure that his or her work meshes well with everyone else’s and with the system as a whole.

• Everyone knows what everyone else is working on.

As you increase the number of IT engineers on a project, the communications issues increase at a much greater rate. There are more possible communications pairs (for the mathematically inclined: n(n-1)/2 pairs for n engineers). The physical distance between engineers of necessity increases (any two engineers are now sitting farther apart), reducing the chances for interactions. And it becomes harder for each engineer to keep track of and coordinate with what all the other engineers are working on.