Learn From Developers: Conway’s Law Is For Everyone

How many of us heard of the Conway’s Law (without googling or wikiing)?

Fifty years ago, Melvin Conway had observed that how the organizational structure strongly impacted on any systems an organization was creating. In his article he wrote:

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” — Melvin Conway (1967).

In other words, two modules will not be able to interact, if their creators cannot interact - therefore, for a functioning system that has earned a system, the structure of final "modules" will reflect the structure of communication of the "developers". The structure of the final and support systems are related. It’s unsatisfactory if the system partition into "modules" ignores the communication and organizational structure of the operators of these "modules".

Simply put,

organizational structure = product design

And there are some strong out of that:

1. Communication dictates design. Communication pathways within the organization influence how the job is one, beyond software architecture and development teams.
2. There is a homomorphism from the linear graph of a system to the linear graph of its design organization
3. Homomorphism exists between linear systems and linear organizational structures.
4. The structures of large systems tend to disintegrate during development, qualitatively more so than small systems.

Brain Mapping Part

There is part of the brain hippocampus called entorhinal cortex which using grid netwokrs help us with structured relationships, from maps of word meanings to maps of future plans. This is a part of the brain where we store all our grids, for example our physical map "how to get from the bus station to your home", which you can do on autopilot after repeating one or two times. But that part of our brain also tends to contain the maps of the social structures. So, organizational structure of the company where we work is also stored in the entorhinal cortex, or even the software architecture or corporate communicational network. And that homomorphism rule kind of brings a force that wants these two different network maps to be similar because it makes mapping easier.

One example from: John, who is working in a traditional organizational structure in the back-end team, notices a feature bug developed for an Android. So, he thinks that he should tell the team about the bug. And now he has to think about who is on that team who is responsible for Android users, like how he has to send the bug to...

Hmmm, Good Question?....

And the answer is pretty straightforward within the software architecture which John, of course, has in his head. So if the organizational structure matches this software grid, then John send it straight ahead to the Android team. It's pretty obvious.

However, if the structures don't match, and let's say this feature is owned for whatever reasons by a CMS team, John has a problem.

To whom shall I talk?

John is trying to map things in his head, fails, and maybe even never reports the bug. So, this is homomorphic force when two maps wanna be similar in your entorhinal cortex, and this leads you back into Conway's law. Technically, it is of course not a law for which ignorance you can be fined or sentenced. But in a common sense if you try to ignore it and build the product (or services) design differently to our organizational structure, nobody is gonna have any clue who to talk to, or who is responsible for anything. And there is going to be a continuing pressure on team to make these things match. Cause their internal maps don't match at all, and the internal fight will exhaust.