Conway's Law
Conway's Law
20 October 2022
Martin Fowler
team organization
enterprise architecture
application architecture
Pretty much all the practitioners I favor in Software Architecture are deeply<br>suspicious of any kind of general law in the field. Good software architecture<br>is very context-specific, analyzing trade-offs that resolve differently across a wide range<br>of environments. But if there is one thing they all agree on, it's the importance<br>and power of Conway's Law. Important enough to affect every system I've<br>come across, and powerful enough that you're doomed to defeat if you try to<br>fight it.
The law is probably best stated, by its author, as: 1
1:<br>The source for Conway's law is an<br>article written by Melvin Conway in 1968. It was published by Datamation,<br>one of the most important journals for the software<br>industry at that time. It was later dubbed “Conway’s Law” by Fred Brooks<br>in his hugely influential book The Mythical<br>Man-Month. I ran into it there at the beginning of my career in the<br>1980s, and it has been a thought-provoking companion ever since.
Any organization that designs a system (defined broadly) will produce a<br>design whose structure is a copy of the organization's communication<br>structure.
-- Melvin Conway
Conway's Law is essentially the observation that the architectures of<br>software systems look remarkably similar to the organization of the<br>development team that built it. It was originally described to me by saying<br>that if a single team writes a compiler, it will be a one-pass compiler, but<br>if the team is divided into two, then it will be a two-pass compiler. Although<br>we usually discuss it with respect to software, the observation applies broadly<br>to systems in general. 2
2:<br>As Conway mentions, consider how the social problems around poverty, health<br>care, housing, and education are influenced by the structures of government.
As my colleague Chris Ford said to me: “Conway understood that software<br>coupling is enabled and encouraged by human communication.” If I can talk<br>easily to the author of some code, then it is easier for me to build up a rich<br>understanding of that code. This makes it easier for my code to interact, and<br>thus be coupled, to that code. Not just in terms of explicit function calls,<br>but also in the implicit shared assumptions and way of thinking about the<br>problem domain.
We often see how inattention to the law can twist system architectures. If<br>an architecture is designed at odds with the development organization's<br>structure, then tensions appear in the software structure. Module interactions<br>that were designed to be straightforward become complicated, because the teams<br>responsible for them don't work together well. Beneficial design alternatives<br>aren't even considered because the necessary development groups aren't talking<br>to each other.
A dozen or two people can have deep and informal communications, so Conways Law<br>indicates they will create a monolith. That's fine - so Conway's Law doesn't<br>impact our thinking for smaller teams. It's when the humans need organizing<br>that Conway's Law should affect decision making.
The first step in dealing with Conway's Law is know not to fight it. I<br>still remember one sharp technical leader, who was just made the architect of a large<br>new project that consisted of six teams in different<br>cities all over the world. “I made my first architectural decision” he told<br>me. “There are going to be six major subsystems. I have no idea what they are<br>going to be, but there are going to be six of them.”
This example recognized the big impact location has on human communication.<br>Putting teams on separate floors of the same building is enough to<br>significantly reduce communication. Putting teams in separate cities, and time<br>zones, further gets in the way of regular conversation. The architect<br>recognized this, and realized that he needed take this into account in his<br>technical design from the beginning. Components developed in different<br>time-zones needed to have a well-defined and limited interaction because their<br>creators would not be able to talk easily.3
3:<br>While location makes a big contribution to in-person communication<br>patterns, one of the features of remote-first working, is that it reduces the role of<br>distance, as everyone is communicating online. Conway's Law still applies,<br>but it's based on the online communication patterns. Time zones still<br>have a big effect, even online.
A common mismatch with Conways Law is where an ActivityOriented<br>team organization works at cross-purposes to feature development. Teams<br>organized by software layer (eg front-end, back-end, and database) lead to<br>dominant PresentationDomainDataLayering structures, which is<br>problematic because each feature needs close collaboration between the layers.<br>Similarly dividing people along the lines of life-cycle activity (analysis,<br>design, coding, testing) means lots of hand-offs to get a feature from idea<br>to production.
Accepting Conway's Law is superior to...