⛓ Conway’s Law

Let’s talk about Conway’s Law.

💡

Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation's communication structure.

🤔 Why you should care about it

“[Conway’s law] is a consequence of the fact that two software modules A and B cannot interface correctly with each other unless the designer and implementer of A communicates with the designer and implementer of B.” - Melvin Conway, American computer scientist, computer programmer, and hacker.

*Conway’s law and org charts, courtesy of @sketchplanations*

😫 Problem(s)

Communication cost increases exponentially with the number of people in an organisation —> The larger the organisation, the more teams need to interact to avoid dependencies or allocate resources efficiently.

Communication issues lead to system design issues —> which, themselves, affect the development efficiency of the entire system.

It’s impossible to solve system design issues without solving communication issues —> any attempt to change a software architecture without changing the organisation will result in more communication issues or defaulting to the old architecture.

😃 Solution

Doing an “Inverse Conway Maneuver” is purposefully designing an organisation to produce the desired system architecture. To do so:

Formulate the WHY —> why are you trying to change the organisation or the architecture?
Identify the WHAT —> what are the expected results (more efficiency, fewer dependencies…)
Plan the HOW —> make organisation changes and the appropriate architectural changes at the same time

💡 Key Concepts

Dunbar’s number —> the cognitive limit to the number of people with whom one can maintain stable social relationships (150 people).

Microservices architecture —> an application architecture where the application is a collection of services, with independent teams in charge of each service.

Monolithic architecture —> an application architecture where the components or functions are tightly coupled and maintained by large teams that share common goals, structure and behaviour.

The Homomorphic Force —> the system's structure preserves itself, even as it moves from one technology to another.

😡 Detractors

“Members of small teams will eventually be more loyal and aligned with their team, rather than the organisation as a whole” —> to mitigate this effect, you can frequently re-shuffle teams to create new bonds and encourage knowledge sharing.

“A monolithic architecture makes it easier/faster to code, deploy and test” —> this is true, especially in the early days of a product where you must iterate rapidly. Yet, as an organisation grows, organisation homomorphism results in large teams with lots of communication.

“Changes at the organisational level are inevitable, but small teams make it almost impossible” —> a “federalist” approach may be interesting here to bound small teams together by covenant with a governing representative head in charge of significant organisational changes.

📚 Top books

😆 Conway’s Law in Big Tech

📝 Content

📄 Exploring the duality between product and organisational architectures: A test of the “mirroring” hypothesis - Alan MacCormack, Carliss Baldwin and John Rusnak —> academic paper empirically proving Conway's law, comparing commercial and open-sources software projects.

📝 Conway’s Law: A Theoretical Basis for the Microservice Architecture - Alibaba Cloud —> article that introduces Conway’s laws and explores whether they offer a theoretical explanation of the concept of microservices.

📼 Trends in Next Generation Applications Real time is Critical - Joshua McKenty —> a criticism of Conway's law.

📝 Conway’s Law v. Software Architecture - Allan Kelly —> interesting post about reverse Conway’s Law and the homomorphic force.