Conway's Law

Melvin Conway's law, also known as Conway's Law, is a principle that states that the design of a system is heavily influenced by the communication structure of the organization that creates it. In other words, the way an organization is structured and the way its teams communicate with each other will affect the architecture and design of the system they produce.

This law was first proposed by computer programmer Melvin Conway in 1968, and it has since been observed in a wide range of industries and fields, from software development to architecture and even urban planning.

For example, consider a software development team that is organized into two separate groups: one responsible for the front-end user interface, and another responsible for the back-end server logic. If the communication between these two groups is poor, they may end up producing a system that is clunky and difficult to use, with a mismatch between the user interface and the underlying logic.

Or imagine you have a development team with a skillset in databases, JavaScript/CSS, and C#. If you build a system, it will likely result in a three-tiered system with a database with stored procedures, a business middle tier, and a UI tier, regardless of whether this is the best design for the system. This is because the team is structured in a way that naturally leads to this type of architecture, which reflects the team's communication structure.

Conversely, if the team were structured differently, such as having a team made up of a data scientist and a DevOps engineer, the resulting system architecture might be very different. They might come up with a flat file for data storage and a command line interface and find this the perfectly acceptable solution. This is because the team's communication structure would be different, leading to a different set of design decisions.

Facebook unintentional architecture

Facebook's statement about their unintentional architecture of their app, FBiOS, looks to me like a another perfect example of Conway's Law. Facebook has stated that over 10 years thousands of engineers have worked in the app. Think about this for a minute: if you have 200 working days per year, this amounts to 2000 working days over a ten year span. If "thousands of engineers" are working at the project, then a conservative estimate could be 1 (or more) new engineer every single day for ten years. How about that?

The fact that FBiOS is built with a combination of C++, Objective-C++, and Swift languages, along with the use of dynamically loaded libraries and heavy code generation, highlights the complex nature of the app's architecture.

I also think that the use of in-house abstractions also illustrate how the organization's communication structure and technical decisions have influenced the architecture of the app. By developing their own abstractions, Facebook's development teams were able to work more effectively on different parts of the app, but it has also led to a more complex and difficult-to-maintain codebase.

Facebook's rapid growth over the years it became necessary to divide the development teams into smaller groups, with each group responsible for a specific aspect of the app.

The other way around

But Conway's law also works the other way around. It's a force that imposes a certain structure on the team who maintain the systems. Take the 3-tier system example from above. Over the years, it has become so complex that each tier requires a specialist to understand and maintain it. The database has many stored procedures, triggers, and constraints, which can only be comprehended by a SQL expert. The GUI is filled with JavaScript and CSS making it necessary for someone dedicated to interfaces to manage it. The middle tier is no exception and also requires specialised expertise to maintain.

However, Conway's Law does provide a potential loophole: if you can create a new system without pre-existing assumptions and communication paths, you may be able to design something new (and hopefully better). In other words, if you can start with a clean slate, you may have the opportunity to create a system that does not simply replicate the organizational structure that developed it. However, this requires a willingness to rethink and reorganize the fundamental ways in which the system is designed and developed.

There's no ultimate answer to the question of how to approach Conway's Law, because it depends heavily on the specific context of the system being developed Generally speaking, it is often more productive to work with Conway's Law rather than against it. This means being aware of the underlying organizational structures and communication patterns that are likely to influence the design of the system, and leveraging these patterns to your advantage. Rather than trying to impose an arbitrary design on the system, it is often more effective to build on the existing organisational structure and communication patterns to create a system that is well-aligned with the needs of the organization. So the key is to be aware of Conway's Law and to learn how to use it to your advantage.

Links:

1. Melvin Conway's original paper "How Do Committees Invent?" which introduced Conway's Law in 1968: https://www.melconway.com/Home/Committees_Paper.html

2. Martin Fowler's article "Conways Law and Its Effect on the Design of Microservices" which explains how Conway's Law relates to microservices architecture: https://martinfowler.com/bliki/ConwaysLaw.html

3. An article on Harvard Business Review titled "Why Agile Goes Awry — and How to Fix It" which discusses how Conway's Law can be used to improve agile development processes: https://hbr.org/2018/10/why-agile-goes-awry-and-how-to-fix-it

4. Allan Kelly on Conway’s Law & Homomorphic force https://www.allankelly.net/archives/638/conway-law-v-software-architecture/