Put Conway’s law to work for you

A while back, we looked at the biggest technical problems holding us back from delivering new features more quickly and reliably. We were looking at our technical debt. When we dug in, we found that most technical problems, or more precisely our failure to solve them, came from the way the company was organized. In my experience, GoodData and other technology companies tend to tackle technical problems by applying a different technology. That brings a different set of problems and obscures the original cause. That cause often fits an observation Melvin Conway made in the 1970s, the basis for the law named after him. This article looks at what Conway’s law says, what follows from it and how it can work for or against us.

In 1968, Melvin Conway described the following principle.

Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure

We used to keep all our source code in one codebase because we had one team, and later two. That gradually became untenable as we grew to several teams, each working at a different pace. It made little sense to have a single versioning strategy when one team delivered new features twice a week and another once a month. We began taking the codebase apart piece by piece, pulling out the components or services that belonged to each team. This worked well for components that had been built later and had a clearly defined team from the start. The process began to drag when we came across code that was split in some fashion but had no clear interface because one team had always worked on it.

That team had always shared one office, two at most, so the separation was little more than a formality. There was no interface to speak of. Why fuss over formalizing an interface when the person using it sits a meter and a half from your desk? You can agree on everything by calling across the room. In other words, the tangle in the original codebase reflected the way everyone had cooked it up together in one room. We put together a team to untangle the spaghetti. They managed to identify the components and the interfaces between them and started refactoring along those lines. As often happens, only the first phase got done before more urgent work took priority.

After a while the problem became pressing again, so we set our plan in motion a second time. This time, though, we spread the refactoring across the teams affected by the split. And absolutely nothing happened. More precisely, each team churned out a list of things it needed from the other teams before it could start its own work.

The design the second time mirrored the organization’s communication structure exactly. We had several teams, each producing a list of tasks it needed done. The first time we had one team that could work without much involvement from everyone else. It’s probably obvious that the second approach is much harder to pull off. Several teams share a goal, but the work is distributed across tasks that depend on one another. I don’t know about your experience, but mine says the second approach rarely works, if only because sustaining the level of communication it requires is hard.

I believe that one ad hoc team, made up of people representing the components from the different teams, would have created clear communication channels and kept the whole effort, the design in the broadest sense, from hitting a dead end. Conway’s law shows up twice here. First, the codebase reflected the fact that the programmers shared an office and talked over one another’s shoulders. Second, the way we designed the solution, splitting up the codebase, reflected how our teams were organized and communicated, by trading tasks.

Conway’s law can work in your favor. If you know the system design you’re aiming for, you can set up teams that mirror it. This applies at practically any stage of development, including the beginning. Suppose you want the front end and back end strictly separate. Your best bet is probably to form two teams, one for the back end and one for the front end. That division gives rise to an interface that reflects the fact that you have two teams. The same can apply when you want a service-oriented architecture. Set up teams that mirror the individual services.

Ways must be found to reward design managers for keeping their organizations lean and flexible. There is need for a philosophy of system design management which is not based on the assumption that adding manpower simply adds to productivity

That was Melvin Conway again, writing when most of the Agile Manifesto’s signatories were still in cradles with pacifiers, diapers or perhaps rocking horses. Every system changes, and the organization’s structure should change with it. We went through this several times at GoodData, when we moved to a service-oriented architecture and when we moved to DevOps. Our system stopped scaling both in terms of people and technology. On the people side, adding programmers no longer gave us a corresponding increase in productivity. On the technical side, adding resources no longer improved performance. After a series of trials, errors and partial wins, we found we could successfully change the architecture only when the way the teams were organized matched it. You can’t say you’re doing DevOps if you still have two departments, Dev and Ops.

Melvin Conway was a keen observer and a visionary. He described exactly how an organization’s structure relates to the architecture or design that it can produce. His legacy is the idea that a system and its changes have to go hand in hand with changes to the organization’s structure.

Notes

• Conway’s law on Wikipedia
• Lukáš Křečan also offered his take on Conway’s law.