#20 Conway’s Law Is Like the Uncertainty Principle
What captivated me about Heisenberg's uncertainty principle when I first learned about it was not just the principle itself but its fundamental nature. It was not the lack of advancements in equipment that prevented the simultaneous measurement of position and velocity. It was nature herself, no matter how sophisticated your measurement equipment is.
Take a pause and think about it. How profound it is. Nature has given us constraints to operate in, non-negotiable constraints.
Conway's law is like the uncertainty principle
There is a similar law in software design known as Conway's law.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
— Melvin E. Conway
Conway stated this law in 1967, but its power was appreciated only when microservice-based architecture became mainstream. Since communication structure is organization structure, people were stunned when they saw how closely service architecture resembles org charts.
Like the uncertainty principle, this law is fundamental and does not depend upon tooling advancement. There have been various attempts to change organizational structure to meet technology needs, especially in the name of agile self-organizing teams. It's futile and breaks the core premise of technology to serve the business and not the other way around.
领英推荐
Domain Driven Design: Celebrating the constraints
Organizational constraints exist because that's the effective way to operate. For example, when I worked for a bank, the production database's unapproved look-up of celebrity account information was subject to immediate firing. I am sure this rule was the same when this bank had mobile branches on a stagecoach in the nineteenth century.
In DDD, these clusters where everything is aligned to a specific function are called domains. A service or a set of services only gets a meaning when looking from the perspective of a domain and therefore is called bounded context. Each bounded context can be a fiefdom with its own rules and model.
Business vs. Engineering
At the aforementioned stagecoach bank, I noticed another interesting dynamic. The engineering and business teams were like water-tight compartments despite being on the same floor. In addition, in all my working experience, I experienced the most organized requirements with minor scope creep there.
This puts into question the idea of self-organizing teams, an agile tenet that sometimes is taken too far. Within a domain or, even more specifically, within a bounded context, self-organizing teams work like a charm. When you cross those boundaries, technology needs to align to respect those boundaries.
One boundary which needs to be navigated skillfully here is between product managers and engineers. Product managers typically either have to sit next to developers (breaking the natural boundaries) or wait for the release to happen before they are able to give feedback. The Roost platform solves this problem.
Roost provides product managers the ability to provide live feedback on a release with the power of preview URLs. It's done during the critical path of a release rather than asynchronous process. Check out https://roost.ai to learn more.