“Show me your architecture, and I will draw you your org chart” is a phrase I’ve heard before, or at least some paraphrase of that. The implication is that a software system will naturally come into alignment with the structure of the team that is building it. Logically and anecdotally, I find this believable, and think that it extends not just to the org chart, but more specifically to the way the team functions.

 
At the No Fluff Just Stuff event this past weekend, I mentioned this in a session where a team lead or manager was expressing concern over how to best manage an offshore development team, 12 time zones away. I got more than a few odd looks from my statement. My suggestion was to align the tasks of this group within his company’s architecture to fit their role in the company. This group is physically separated from the main development team, and does not frequently communicate with the team via ad-hoc methods such as instant messenger and quick phone calls, rather they use scheduled conference calls and high latency email exchanges to communicate. These communication channels are more formal than most, and the relationship is not often based on getting an immediate response. As such, it seems natural to me to assign them tasks, components of the system that communicate with the rest of the system through a more formal, documented interface (compared to communication between subsystems of the U.S. teams that are in the same office), less synchronous. It suits the structure better.

 
While the initial intent of the phrase is more of an observation than a basis for action, I’m interested in seeing if it can be taken one step further. Can a change in the way an organization functions effect a change in the way its software is structured? While bugs are a fact of any software of any complexity, reducing the number of bugs is still often a worthwhile pursuit. In my perception, a large proportion of our bugs are due to communication lapses between the different systems of our application. Each component, on its own, is generally fairly well written – it’s the nuances of communication between them that’s a challenge. Similarly, our team is a collection of effective individuals, but we rarely work together on a task, and even less frequently meet together as a team. My theory is this – that by adding weekly stand-up meetings to our schedule, we can increase the level of awareness of what each of us is working on, increase the amount of informal communication between us, and consequently improve the quality and correctness of communication between our application’s components. Wacky, or worthwhile? Not sure. But having a 10-15 minute standup meeting each week is probably worthwhile anyhow, so to experiment with this idea in the process will be interesting.