Your software product and Conway’s law

There are many different ‘laws’ that influence the tech world. From the long arm of Brooks’ law to Murphy’s law positing that anything that can go wrong, will.

One important law for any software company to know is Conway’s law. Conway’s law describes a phenomenon that sees the software we create mirroring the communication structures within an organisation.

Here, we look deeper into Conway’s law and what it means for your software product.

What is Conway’s law?

Conway’s law is an adage named after Melvin Conway, the computer programmer who outlined the idea in 1967.

His original wording of the law reads:

“Any organisation that designs a system will produce a design whose structure is a copy of the organisation’s communication structure.”

Melvin Conway

In other words, your software product’s “shape” will reflect the way your team(s) work together.

In example…

But what does this mean exactly? The best way to understand Conway’s law is through examples.

For instance, consider a software development team that works in close quarters with each other. Perhaps as part of a small company in which communication is as simple as turning to the person next to you, or walking down the hall. These types of teams are more likely to create software that’s monolithic. That is, a single, large program.

On the other hand, consider a large, multinational company. One where the development teams are spread out. These teams cannot rely on the same type of communication as a small office. As such, their software product is more likely to be modular. For instance, following the popular microservices style architecture.

Conway’s law isn’t about the size of the company. Rather, it’s about the way the development teams integrate. Close-knit, monolithic teams with constant, easy communication are more likely to develop more monolithic codebases. Meanwhile, loosely integrated teams divided into groups are more likely to create more modular codebases.

Why it’s important

So, what makes Conway’s law so important for software businesses to know?

Simply, you can’t ignore it. Even if you plan a modular, microservice style software, for example, but have a monolithic team, implementation is at risk of still seeing the software gain monolithic functionalities.  

Plus, if you change your organisational structure, there’s a good chance those changes may also end up reflected in your software, too.

Additionally, having a poor communication structure — and teams that don’t collaborate well — can end up reflected in the interfaces of your software. That is, you will have software that feels clunky or doesn’t quite gel together.

What Conway’s law tells us

  1. Effective organisational communication is more important than you might think

While it’s obvious that effective communication within an organisation is important, Conway’s law demonstrates just how important it is. The way your teams communicate has a ripple effect that will impact the work they produce.

  1. You can’t change the architecture of your software without changing the way that your teams communicate — and vice versa

If you have a monolithic software product, but want to transition to a more modular one, for instance, Conway’s law says you cannot do this without restructuring your teams and their communication accordingly.

  1. When structuring new projects, you need to start with people

Similarly, when it comes to new software projects, when you know the structure you want, start by organising your teams and communication. It’ll make development of the software you want much more conducive to your roadmap plans.

Design your organisation to design your software product

People are at the heart of businesses. They’re at the heart of innovation. And, as Conway’s law demonstrates, they’re at the heart of your software.

The way we interact and communicate with each other shapes how we can make things. It would be hard to create something that’s fluid and one whole piece, if our communication is not the same — there’d be no way of knowing how things would fit together.

All this is to say, when it comes to designing your software product, the best place to start is by designing your organisational structures. Start with your people.

Useful links

Ten laws of software development

Beware the long arm of Brooks’ law