I am aware of this theoretical law but never really considered it. I suppose this could explain why I encountered such push back against a distributed SOA architecture on commodity hardware at a large organization that was built around centralized systems using mainframes.<p>Ultimately after three years of justifying and re-justifying the decisions I made for which they explicitly hired me for I moved on. It was abundantly clear that though they brought me in to implement SOA and lower physical costs, the culture just did not support that decision. What struck me as odd was that fact that those who hired me to do it did not seem to support it either.<p>I should note that Conway's law seems like a reasonable assumption as to why due to the monolithic and centralized nature of communication there. It was considered "taboo" to walk in to an executive managers office to speak to them. The expectation was to follow this ridiculously verbose chain of command whereby response to even a simple question could take days or even weeks.
"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."<p>I'd say that organizations are not just constrained to do that -- they should. When you design systems and infrastructure, keep in mind that systems and solutions are under evolutionary pressure, and engineers have to change it all the time. When optimizing for change, you need to optimize for teams and interactions.<p>If the whole team is sitting in the same room, then there's nothing wrong with a monolithic app and shouting to others that 'hey, does anyone have a problem if I release the latest master branch?'; or it's also fine to have a QA server that the team is using. At a remote company, it's much more important to be able to test subsystems in isolation or even without internet access, automated integration tests are more useful and important.<p>And so on.
If it is one thing that I have learned at a large software company it is the fact that Conway's Law is fundamentally true. Any software system is a mirror of the team setup and the interactions between the involved people. And many bugs are found in the interfaces/interactions between components of isolated teams.<p>However, this also means that as a software developer you are unable, or at least very constrained, in the ability to improve or refactor any complex legacy system. You are basically fighting uphill battles in such situations, because you are not in the authority to change/improve the organizational structure.<p>This also means that as programmers we may need to take more time and care to invest in human relationships and in our communication skills, as this could have an significant effect on code and product quality.
Conway's Law validates a decision to move to a service-oriented and/or microservice architecture. Each service ~= a business unit or department.<p>Even better is that such an architecture requires (or at least greatly benefits from) specifying precisely the communication between the interacting parts in the form of interfaces.<p>IIRC there is a study that Steve McConnell mentions in one of his books (sorry, I can't find the link) that shows that the number of bugs introduced into system is highly correlated to the number of lines of communication between the people or teams that write it. Add another team and that number potentially rises exponentially. Conway's Law is the scaffold on which all these understandings hang.
I feel old when these kind of Wikipedia pages make it to the front page and I was assuming that it was known and obvious for everyone. </grand parent mode off>
It's maybe interesting to consider Conway's Law in respect of the systems designed by IETF Working Groups (as distinct from the wider scope of systems that have an RFC but were designed wholly outside the IETF or brought to the IETF largely finished for just a bit of spit and polish)<p>Whether the IETF is an organisation per se is a fun question in itself of course since it has no membership. It is clearly an activity, but so is break-dancing or reading poetry and we do not suppose that people who read poetry are an "organisation". But if it /is/ an organization, then is that organisation reflected in the things it designs?
This also applies to performance. Nobody cares that the system is nightmarishly slow in bureaucratic corporations where even the simplest software projects take 6 months minimum.
Some previous discussions over the years: <a href="https://hn.algolia.com/?query=Conway%27s%20Law%20points%3E3&sort=byDate&dateRange=all&type=story&storyText=false&prefix&page=0" rel="nofollow">https://hn.algolia.com/?query=Conway%27s%20Law%20points%3E3&...</a>
I often see this in the company webpages. Does a college organize for new students? By division? Department? You can tell a lot about the college culture based on how the website is organized!
I always suspected this could be applied to civilization and the human mind as well - that the structure of society has some similarities to the structure of our brains.
Have anyone deep dived into this ? I'm interested in learning more. What is the most common communication structures and what designs does those correspond to ?