Have you ever thought about the printer paper you use in your office, and how it affects the design of your software? Probably not. In fact, it sounds like a stupid idea. What possible effect could your printer paper have on the design of your software? I might as well be asking about the brand of shoes that you wear. But, the fact is, there are subtle things which affect the design of software in substantial ways, and often they aren’t at all obvious.

A few years ago, I visited a company that was transitioning to Scrum. I came in to help them with some code and design issues and I showed them a variety of ways to change their design to make their software testable. One of the recommendations that I gave them was to avoid using the complete set of the techniques that I showed them. I told them that it would be good get together as a team and decide which subset of techniques they’d use in particular circumstances so that that their design didn’t end up becoming a hodge-podge. “Oh”, they said, “that will be hard. Since we’re doing Scrum, we can all be moved from one team to another every sprint. It’s Collective Code Ownership!” I puzzled it a bit and replied, “No, that’s no ownership at all.”

Unfortunately, I’ve seen this scenario a number of times. The original idea in Agile was to avoid development silos – to make sure that on a team there are there is no one person who is the only one who knows how to do X. It keeps the team unblocked, and gives everyone the opportunity to do more than one thing. But, all messages dilute over time. In some organizations, “collective code ownership” means that they can staff projects like fishing expeditions. “We need a captain, two linesmen, an engineer, and five deckhands.” What they’re missing is the fact that you need to know the area to catch fish. That ocean is the one persistent thing in the fishing scenario, and code is the one persistent thing in development. If you don’t have it in mind when you make decisions, it will own you. In the no-ownership case, the failure mode is an ocean of code that is unintelligible. It looks like it was tended by dozens of short duration crews of people that didn't talk to each other, because it was.

Here’s the truth about software design and team organization. Fred Brooks attributed it to Mel Conway back in the 1970s:

Conway's Law: Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure.
Or, colloquially: Software is doomed to reflect structure of the organization that produces it.

There are a number of reasons for this, more than I can get into right now, but it is a truism. If you want to design a large system well, you have to design the organization that will work on it. Systems mirror systems. And.. when you think about it, it makes sense. How can we possibly expect cohesive software without cohesive teams?

Conway's Law isn't exactly forgotten lore.. you can see the idea in the writings of Eric Evans and Jim McCarthy, but nonetheless I am running into a number of people who haven't heard of it. Once you understand Conway's Law, you see it all around you, and you're less surprised when you see software efforts with misaligned project structure failing. Team structure is a hidden influence on software design. It's more important than the industry currently recognizes.