Distributed Development (Part 1) - Bruce F. Webster: Lack of Conceptual Unity

On top of or in place of this, imagine actual dislocation: engineers on the same project too far apart to walk over and see each other─whether they’re in different buildings, different cities or different countries. Add to that significant differences in time zones, cultures or even languages, and you can began to see why such efforts often fail.

Yes, the engineers can pick up the phone, chat via instant messaging or send e-mail. But any software engineer will tell you that’s not the same as impromptu sessions over a cubicle wall, in each other’s office, in the hallway, at a whiteboard, or while eating pizza together late at night─in each case with other engineers joining in as they hear what’s being hashed out. One senior engineer I know spent two of her four years on a large software project in a different state from the rest of the development team. She talked about how much out of the loop she felt during that time and how limited she felt in her ability to make contributions to technical issues in the project.

This communication issue leads to a lack of conceptual unity within the software itself. Fred Brooks famously talked about the need for conceptual unity in large software projects and, thus, the need for a chief architect. However, as Tom Affinito once told me, architecture is a political act that requires constant interaction with other team members to increase understanding, gain buy-in, and establish consensus regarding the foundational principles and aspects of the system.

Such architectural politicking is hard enough with a development team all in one location. When the team is distributed, it can become very difficult. As a result, the developers began to drift from one another in their understanding of how the system is intended to work and to fit together. You can end up with subsystems that may both adhere to a documented API but that have some deep internal mismatches on what leads up to or happens after a given API call.

I remember one project for which I was chief architect where we had two groups of developers, one on the West Coast (where I was) and one on the East Coast. I wrote plenty of architecture documents, sent e-mail and made phone calls to those on the East Coast, and we even had some videoconferences. But I found it much harder to bring the East Coast developers in line with what we were going to develop; the bandwidth just wasn’t there. To make matters worse, we were on a very tight schedule (despite my strenuous objections).