This blog post was originally going to be called “does corporate management structure mirror the architecture of a modern day computer?”. I began writing, and during my research a colleague put me onto something called Conway’s law. Conway’s law is the idea that companies and organisations design systems that run parallel to their communication structure: “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.
At first I thought this may be a stretch, so I was shocked to find countless web pages and papers published all about Conway’s law. On reading further I realised that the reasoning behind the law made more sense than my impulsive idea to try and compare corporate structure to computer hardware. The law was born out of the idea that in order to build a large piece of software, there must be multiple authors and potentially stakeholders/clients communicating frequently. Proof of this can be found in the fact that Github holds more than 100 million repositories and over 40 million users. There is clearly a requirement for collaboration. Therefore, the software interface structure of a system will reflect the social boundaries of the organisation that produced it.
A paper titled ‘Exploring the Duality between Product and Organizational Architectures’, published by the Harvard Business School, ran a study across multiple codebases to test Conway’s hypothesis. In this paper they use the term ‘the mirroring hypothesis’ in place of ‘Conway’s law’. The study showed that source code created by tightly coupled teams (often co-located) tends to be more monolithic, in comparison to the code produced by loosely coupled teams (potentially with a remote working structure), which tended to be more modular. This strongly supports the mirroring hypothesis—Conway’s law.
Companies and organisations who appear to have consciously used Conway’s law to determine the outcome of their software product show to be very successful. Spotify, for example, use ‘squads’ which is a similar approach to scrum methodology where each team (approximately 6-12 developers) work on their own feature area. Due to Conway’s law, this generates modular code bases which have clearly proven effective for the company (assuming that Spotify teams actually work this way—Ed.).
Working at a management consultancy, this brought me to question how the communication relationship between developers and non-technical people (such as traditional consultants) can affect the structure and nature of source code. In a situation where the consultant has strong input on a project, this would make the source code more modular. This is more due to the fact that features might change so it makes more sense to have a more decomposed codebase which allows you to plug-in/remove different features without added work and complication if a design decision changes. At first I thought this was a good example of Conway’s law that I’ve seen first hand in the workplace. However, I then realised that it has nothing to do with the communication structure as such. Arguably it’s more that changes in requirements and scope lead to a modular codebase.
The next thing I considered is how Conway’s law has held up over the years, and how it will hold up in the future, and the kind of software that will be created. Due to Covid-19, most if not all developers are currently working from home. This is forcing organisations to have to work in a decentralised manner. Assuming that productivity remains the same, this may cause organisations to modify their remote working policies). At first this may suggest that all codebases built by organisations will become modular and decomposed code. I don’t necessarily agree.
With the rise of tools like Atom and Microsoft Live Share, which allow for live collaboration on code and give teams a way of pair-programming effectively, the reason for code staying modular may have nothing to do with communication structure. Having multiple authors working on a document simultaneously works well and can cut out major overheads, as I experienced the other day when working on a monolithic codebase with someone else who was also working remotely. The fact we were located at opposite ends of the country did not change the fact that the code base was monolithic. This may have been down to the fact that the team working on this code base was small and it started out monolithic, with only one author. But the point still stands that the outcome of future software design is vastly more complex than the argument that “everyone is decentralised therefore every code base will be heavily modular”.