Jay Bazuzi was talking about how to make the work of distributed teams run more smoothly, and there was a term he used that I thought deserved a little googling...

There are a bunch of known good practices to help distributed teams not suck too much. Doing them won't get us to "awesome", but at least we can get up to "not sucky". So let's start by writing down these practices:
...

• Recognize the expression of Conway's Law: limited communications affect software architecture

As it turns out, Conway's Law is pretty interesting. Here's some more, from Demystifying Conway's Law on ThoughtWorks:

In "Exploring the Duality between Product and Organizational Architectures", a study by The Harvard Business School carried out an analysis of different codebases to see if they could prove Conway’s original hypothesis as applied to software systems. In it, they took multiple examples of software created to solve the same purpose (for example word processing, financial management and database software), and compared the code bases created by loosely-coupled open source teams, and those created by tightly-coupled teams. Their study found that the often co-located, focused product teams created software that tended more towards tightly-coupled, monolithic codebases. Whereas the open source projects resulted in more modular, decomposed code bases. [emph mine -mfn]

The real take-home comes just a little later, though, I think:

You may see tensions in your own organizations where your structure and software are not in alignment. You may have seen for example the challenges involved where distributed teams try and work on the same monolithic codebase. [emph me again -mfn]

That the work of distributed teams -- or, if you ask me, any team -- can be coordinated more easily when you take the time to clearly define the interface surrounding their work seems like a truism.

Though I'd never given the converse enough thought. If you have a widely distributed [read: "entirely remote"] team that doesn't tend to communicate, having a monolithic codebase, especially one without documentation, can absolutely hamstring development. Or, at best, it means that your team will tend to ignore what exists and replace with whatever seems best.

If you start eating away at the monolith in good, interfaced, discrete chunks, however, that's probably about as good as means of erasing it as you can get.

Regardless, I think the lesson here is that the downfalls of poorly documented, monolithicly designed codebases are compounded in easy to identify and productivity unfriendly ways in distributed/remote work environments.

Say that three times quickly. Even better: Remote environments require well factored code.

Labels: coding, monolithic, productivity, remote, style