Conway’s Law states that “organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.” It’s a principle that highlights the relationship between the systems being built and the organization’s structures. Not understanding this relationship can result in system designs that teams struggle to work with. However, by accepting Conway’s Law, you will make decisions that better support all the engaged teams on the project.
What It Is
The law is based on an observation Melvin Conway made more than 50 years ago, one that is still relevant today. He stated that the architecture of a system looks similar to the communication model of the teams that built it.
When developers can easily talk with whoever wrote the code, then they can build a deep understanding of it. This includes all the assumptions and thinking of the problem domain. As a result, the code written by the team members will be strongly connected to that code.
As multiple authors work to write code together, the system structures will eventually become a mirror image of the organization that produced it. This includes the values of the organization concerning quality, complexity, and waste in the development effort. Knowing this will help you understand how to approach designing systems when working across a variety of business challenges.
With small teams, Conway’s law doesn’t have the same impact since the team can have deep informal communication. However, as the number of development teams scales across an effort, you should embrace Conway’s Law in the design of a system. This is especially important when considering geography, as distance can make regular communication challenging.
Common Patterns of Impact
Conway’s Law can impact your work in several ways.
Consider the potential for misalignment between an external consultant team and a corporate development team. External consultants may have their own processes, tools, and methodologies that differ from those of the corporate development team. If you don’t reconcile these differences at the beginning of a project, they can lead to a system that reflects the disjointed communication structures between the teams. To mitigate this risk, the teams should decide on a shared process they’ll use to establish a framework for collaboration.
Another common challenge happens inside large corporate organizations. If the company has a hierarchical structure with siloed departments, the resulting software system may reflect that siloed approach. This includes different components developed separately and without adequate integration. This often manifests in poor, disjointed user experiences as the user navigates across a company’s different software systems.
Furthermore, an organization’s culture can influence how the systems will be designed. A culture that values hierarchy and deference to authority may follow a waterfall process in building systems. The project orientation may result in systems that have a more centralized architecture with fewer points for integration. However, a culture rooted in collaboration and openness may result in a decentralized system with an agile process for managing the work.
Embracing Conway’s Law for Better Solutions
To avoid painful solutions, organizations should create strong lines of communication between all development teams. They should also ensure that there is a shared understanding of the goals and objectives of the project. This will help align the teams and ensure the software system reflects a unified approach.
Another way to ensure Conway’s Law does not impact the system negatively is to focus on creating a modular architecture. By breaking the system down into smaller, more manageable parts, it becomes easier for the teams to work together cohesively. This also helps reduce the impact of any misalignment between the teams.
Finally, ensure both teams have a shared vision for the software system. This means that, when possible, they should work together to define the architecture and design of the system. This way, they can ensure the software system reflects their shared vision, and they’re not impacted by communication issues between teams.
Conway’s Law and Change
Be mindful that large projects that run for long periods will experience moments of big change. When the change is large and involves new teams, be aware of Conway’s Law. It may be time to examine the system design and determine if changes should be made to better align with how the teams communicate.
Keep in mind that Conway’s Law is not a hard and fast rule. Rather, it is something that can be seen in many organizations. The goal is to be aware of how your organization communicates and how this may affect the systems you build. In this way, you can make changes to improve the overall efficiency of your team and the quality of the final product.