In this episode, I introduce Conway's Law, which talks about how our software structures will reflect the structures of the organisations that create them. Why you might be Interested in this episode:
Or listen at:
Published: Wed, 04 May 2022 15:57:46 GMT
Links
Transcript
Hello and welcome back to the Better ROI from Software Development Podcast.
In this episode, I want to introduce Conway's Law, which talks about how our software structures will reflect the structures of the organisations that created them.
You may be interested in this episode if you want to understand:.
- Why our organisation structures affect software structures
- The history of Conway's Law
- The negatives the law can help us highlight.
- And why the adoption of microservices and small cross-functional teams help us to alleviate that.
Wikipedia described Conway's law as:
"Conway's law is an adage stating that organizations design systems that mirror their own communication structure. It is named after the computer programmer Melvin Conway, who introduced the idea in 1967. His original wording was:
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
The law is based on the reasoning that in order for a product to function, the authors and designers of its component parts must communicate with each other in order to ensure compatibility between the components. Therefore, the technical structure of a system will reflect the social boundaries of the organizations that produced it, across which communication is more difficult. In colloquial terms, it means complex products end up "shaped like" the organizational structure they are designed in or designed for. The law is applied primarily in the field of software architecture, though Conway directed it more broadly and its assumptions and conclusions apply to most technical fields."
On his website, Melvin Conway provides a bit of history about the law - I'll include link in the show notes - but it was originally part of a paper that he submitted to the Harvard Business Review called "How Do Committees Invent?"
This was rejected in 1967 due to Melvin having "not proved the thesis".
The article was later published in 1968 in Datamation, a major IT magazine at the time. It was then referenced by Fred Brooks in his book "The Mythical Man Month" - where the name Conway's Law was first applied.
Since then it has become a staple of the agile movement - anywhere team structures are mentioned, then Conway's Law is going to be referenced.
Again, I'll link back to his website in the show notes.
So as the Law state, we will often find software structures in line with the organisational boundaries. Take for example, most corporate websites. They are structured based on the internal teams - rather than normally for the needs of the user.
I've talked many times that anywhere there is a boundary for a team, there is additional work needed to cross that boundary. Crossing that boundary becomes increasingly complex when the parties either side have misaligned goals and incentives.
We quickly find we develop communications problems and "them" and "us" mindset. You may observe it with teams reinventing the wheel, or complaining about insufficient cooperation, or blaming others, or defending their responsibilities.
We become siloed and fragmented as people.
Thus, is it any surprise that our software takes on those same characteristics?
And this can be seen in our traditional monolith applications. We would develop them in a waterfall manner between teams siloed by technical disciplines, be it business analyst, architect, developer, tester, operations.
Each team maintaining separation from each other by reams of documentation, handovers and ever increasing complexity levels of project management.
And we would then make it even worse by splitting those monolith applications into layers. Be it, for example, a frontend website, middleware and backend - each with their own collection of business analysts, architects, developers, testers and operations.
And yet more layers of complexity and coordination heaped on top.
It starts to become a wonder that anything ever got done at all.
So is Conway's Law in itself good or bad?
In truth, it's neither. It's an observation of the impact of organisational structure over our software.
In the same way, as I've talked about the pros and cons between having the legacy monolithic application versus the more modern distributed microservice, there is no clear cut best way. It depends on your organisational and customer needs.
I would, however, say that many organisations are heading towards that smaller microservice architecture as a means of being able to adapt rapidly to change, and adjust to market pressures.
The generally accepted approach is to make smaller, more cross-functional teams aligned to those microservices. By then providing each team with the responsibility, authority and resources to be able to design, build, test, deploy and maintain the microservices, then the boundaries are rarely crossed - making us much more effective.
And this restructuring of the team, and thus your organisation, is an example of using Conway's Law - sometimes known as the Inverse Conway manoeuvre - to our benefit. And this will be the topic of my next episode.
In this episode, I've introduced Conway's Law and how it helps us to understand why our organisational structures affect our software structures. I gave some history on the Law and why it is now an accepted principle within agile development. And I talked about the natural result of common attempts to resolve the negatives highlighted by Conway's Law in the use of microservices and small cross-functional teams.
Thank you for taking the time to listen to this episode and I look forward to speaking to you again next week.