Conway's law
The first time I heard about Conway’s law, I was amazed; it is not common to view a “law” in software development. I don’t want to enter into a naming discussion, but this awakened my interest. So let see what it is all about.
Conway’s law is named after Mel Conway, who in 1968 published a paper in Datamation magazine, How Do Committees Invent?. In this paper, Conway explored the relationship between organizations structure and software architecture. The most remarkable part is on the conclusion when it says:
Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
– Mel Conway
That words were the starting point, but there are other definitions for this law that can be helpful to understand the point.
The structure of any system designed by an organization is isomorphic to the structure of the organization.
– Eduard Yourdon and Larry Constantine on Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design
This is saying that the communication structure within the organization has a strong influence on the resulting system design.
In other words, the resulting possibilities about the software architecture of a system are constrained by the organization communication structure, therefore also the organization structure. So it is essential to keep in mind that the organizational structure can be a limiting factor to achieve a system architecture design.
I like this Sketchplanations image, a quick way to understand the concept.
This means that it is not enough saying “we want to go to this architecture”. When thinking about the system design we want to achieve, we must consider the organization structure because it can be a limiting factor. In the words of Mel Conway:
Given any design team organization, there is a class of design alternatives which cannot be effectively pursued by such an organization because the necessary communication paths do not exist.
– Mel Conway
Let’s put a simple example; If you have only one DBA team in your organization and is the only one with the superpower to manage and maintain the databases. It is more likely that your resulting system design has a single database. Despite maybe you have three teams working on completely separated projects with different APIs, repositories codes, etc.
So if you want that each project has its own database to avoid database coupling, you will have more chances to achieve it if you give each team the ability to manage and maintain the database. It does not mean that each team must know everything about the Database Administration world, but in this way, you are changing the organization structure, therefore influencing the system architecture possibilities.
This way of thinking is commonly called Inverse Conway Maneuver. The idea is to take advantage of Conway’s law, altering the organization structure to increase the possibilities to reach the desired system design. Inverse Conway Maneuver is an excellent concept to keep in mind in a world being dominated by microservices.
Evidence
I want to talk a little about the evidence about this law. Software development is not like physics or any other mathematical based science. We have not a mathematical formula to prove that this statement is true. But we have empirical proof in many companies and projects, each with its characteristics. You may have experienced this at some point.
The most relevant research that I have found is “Exploring the duality between product and organizational architectures: A test of the “mirroring” hypothesis” research at Harvard Business School. In this study, Alan MacCormack, Carliss Baldwin, and John Rusnak compared the different software systems, some of them were open source projects, and others closed ones. The results showed that loosely organizations, like open source communities, tend to make more modular loose coupled systems than the other more tightly organizations. Typically, a company have clear goals, that helps to all organization to align to achieve it, creating a more tightly organization.
So the next time someone out of the world of development says to you that we are like wizards, you can regard him that there are also laws in the wizard’s world.