« Programmers Who Can't Write Strlen() | Main | Tagging O.J. »
November 20, 2006
Potential Benefits of Distributed Development
One difference between Google and Microsoft is that Google is actively embracing remote development sites. Microsoft is actually getting more distributed than we used to be. For example we bought a company called Vexcel that is headquartered in Boulder, Colorado, and unlike in the early years when we likely would have moved them to Redmond, they are staying put in the shadow of the Rockies (that linkted-to page on Vexcel's site, plus other ones like this, are funny because someone obviously did a search-and-replace of "Vexcel" with "Microsoft", leading to off-kilter phrases like "Microsoft's worldwide presence is magnified by its Australian and Chinese sales offices" and "Microsoft Corporation's headquarters in Boulder, Colorado"). But Google seems to be racing to establish as many remote sites as possible, independent of acquisitions.Google is going this, apparently, to hire as many people as they can who don't want to relocate to Silicon Valley. And I don't know whether they plan to segment their products to certain sites (Talk over here, Search over there) or mingle them all together, although the rumors I hear are about mingling. The mingling fits in with a theory I am incubating, which is that distributed development is actually a good thing for a product.
I don't mean the obvious ways, such as a distributed team likely being more diverse, or being able to work on the product for more hours each day. What I am talking about is a distributed team being forced to use techniques that result in higher-quality software.
When we talk to teams about quality, a lot of what we emphasize is up-front planning. Meaning that you really think about your design, and your interfaces, and how pieces fit together. And there's another area we need to focus on that is coming out of some of the analysis of Windows bugs that are being done: the time between design and coding. These are things that are too minor to be part of a design document and design review, but need to get figured out before you start coding. Like knowing precisely what that API parameter or registry key means before using it. For lack of a better term, we'll call it "personal design review".
My concern is that having your team all in one place makes you lazy about this kind of thing because you figure that you can always ask the person next door for details when you need them, and if you get some part of your design wrong you can have a quick hallway meeting to sort it out. With a distributed team, especially one that is time-shifted, you know that it is hard to fix these things later, so you take the effort to design and document them right to begin with (open-source development creates essentially the same effect). So, in this case, it could indeed be that "absence makes the code grow better" (or something like that).
Posted by AdamBa at November 20, 2006 09:01 PM
Trackback Pings
TrackBack URL for this entry:
http://proudlyserving.com/cgi-bin/mt-tb.cgi/520
