Distributed Development
We Bokonists believe that humanity is organized into teams, teams that do God's Will without ever discovering what they are doing.
—Kurt Vonnegut
Then there's time-zone-shifted programming: Offshoring, outsourcing, nearshoring, open-source collaboration. Distributed development, in other words. As explored here in the June 2007 issue with regard to software development in Eastern Europe, it is increasingly common to have programming teams whose members work in different time zones. Motorola, Symantec, Qualcomm, and Freescale are just four examples of companies with labs in multiple countries, doing software development across time zones.
This can work well, apparently, at least sometimes, for getting the coding done. But it is likely to wreak havoc with the Build process. "You can't have a single central Build-meister fixing all of the problems," Ousterhout says, "when half of the team is in India and half is in Silicon Valley. The Silicon Valley Build-meister isn't even awake when something breaks in India."
The more distributed the development process is, the more need there is for automation of the Build process. "In general," Ousterhout says, "you need more automation for the interactions between teams when they don't overlap in their work shifts."
So the increasingly globally distributed nature of software development is also a factor.
