“Conway’s Law: Why your company’s organisational structure affects your software”.

Software Development and Conway’s law

In software development, there are many factors that can influence the quality and success of your project. One of these is Conway’s Law. This law states that the structure of a system developed by a team tends to be similar to the organisational structure of the team itself.

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

Melvin Conway formulated the law in 1967 and it describes that the way a team is organised influences the code it writes and that the architecture of a system is a reflection of its developer organisation.

This law has been proven to be true time and time again over the last few decades. Many successful companies have realised that it is important to have a good organisational structure in order to successfully develop software. However, a poor organisational structure can lead to problems such as poor communication, slow development times and a lack of collaboration.

Examples

Good examples of this have been created by Eric S. Raymond in the Jargon File or Tom Cheatham. They have both shown that a “compiler” developed by 4 groups will become a 4-pass compiler, or Tom Cheatham goes even further and says that a number of groups will create an n-1 pass compiler because one will probably be a manager.

Another very good example are corporate websites, and in particular classic intranet websites, because they are broken down by organisational structure (HR, IT, Finance,…) and have not dealt with user requirements i.e. “the complete onboarding process involving all departmements” as a structure.

It is important to understand that Conway’s law does not mean that the organisational structure of a team is the only criterion for the success of a project. There are many other factors that also need to be considered. However, a good organisational structure can make an important contribution to the success of a project.

An example of which is the concept of “Agile Project Management”. This concept emphasises the importance of a flexible and adaptable organisational structure in order to be able to react quickly to changes. By using agile methods such as Scrum and Kanban, teams can adapt their organisational structure and thus guarantee better software development.

Amazon and Netflix have also addressed this topic and focused on many small teams for their architectures with microservices. Amazon calls this approach “two-pizza teams“, meaning that no team should be bigger than two pizzas in one meeting. This team organisation should lead to better collaboration between the teams. According to Conway’s Law, this also leads to software that communicates better with each other, as is strongly recommended for microservices.

Scientific papers and other reverences

If you want to delve deeper into the topic, you can read a paper from Harvard University entitled “Exploring the duality between product and organisational architectures: A test of the “mirroring” hypothesis” . The paper is very data-orientated and therefore provides evidence for “Conway’s Law” that is still valid today.

Spoiler

This study makes an important contribution to the academy and practicing managers. It finds strong evidence to support the hypothesis that a product’s architecture tends to mirror the structure of the organization in which it is developed. In all the pairs we examine, the loosely-coupled organization develops a product with a more modular design than that of the tightly-coupled organization.

Conclusion

Conway’s law is an important aspect in the world of software development. It shows that the way a team is organised has a direct impact on the quality and efficiency of the software developed. Companies should therefore consider a well-designed organisational structure to maximise the success of their software project.

This also translates into Infrastructure and Operational project, when you try to operate very agile in this part of the organization, but the organization by itself is very classic / waterfall organized, than you are setup for failure.

For more basics on IT Architecture please check here.