Home Blog Software Development What is Conway’s Law and why does it matter when choosing a digital development partner?

What is Conway’s Law and why does it matter when choosing a digital development partner?

There are times when you could be forgiven for thinking that the most relevant law in life is Murphy’s law: anything that can go wrong will go wrong. And sure, there are times that applies to software development as much as any other endeavor. But far more applicable to the creation of digital platforms, apps, and websites is Conway’s law. Read on to find out what Conway’s law is, how it applies to digital development, and how it can help you find the best development partner.

What is Conway’s Law and why does it matter when choosing a digital development partner?

Table of contents

What is Conway’s law?

Conway’s law comes from a 1967 paper by Melvin E. Conway in which he stated:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

This is based on the fact that efficient and effective software development depends on communication: between designers and developers, product owners and stakeholders, not to mention users and anyone else with an interest, influence, or role in the creation process. Put another way, Conway’s law implies that the quality of a digital product is reflected in and linked to the working methods and innovativeness of the business (or businesses) that produce it.

As an example, imagine a digital product consisting of various modules. If those modules are created by different developers, the efficiency of how those modules interface will depend on how well the different developers (or development teams) communicate with each other. A more basic example would be a company website whose structure mimics the organizational structure of the company.

You might be also interested in the article:

What skills (apart from coding) should a developer have?

What skills (apart from coding) should a developer have?

Conway’s law examples

An early indication of the truth of Conway’s law can be found in a 1997 study by Nigel Bevan, “Usability issues in website design”. The focus was on the importance of website development being user-centered. The paper noted that, at the time, many websites were slow and difficult to use. One of the reasons given was, “Organisations often produce websites with a content and structure which mirrors the internal concerns of the organisation rather than the needs of the users of the site.” Hopefully, websites are much improved in the year 2022… but then again, can we honestly say that all websites these days are user-friendly and intuitive-to-use? Or is Conway’s law at work?

Do you remember Vista OS? It’s often remembered now as one of the worst operating systems from Microsoft. There were certainly plenty of bugs, and although many would cite ME as the worst OS ever (your mileage may vary!) it seems to be Vista that everyone remembers. In 2008, Microsoft conducted an analysis using Vista as a case study: “The Influence of Organizational Structure On Software Quality: An Empirical Case Study” This research established a set of metrics to quantify organizational complexity in relation to the product development process. Based on the actual data from Vista, the study concluded that, “the organizational metrics… were statistically significant predictors of failure-proneness.

You might be also interested in the article:

Everything you should know about user testing

Everything you should know about user testing

Implications of Conway’s law

The year 1967 might seem pretty distant, but Conway’s law has survived and been shown to have worth many times, both academically and in practice.

For instance, a 2011 paper “Exploring the Duality between Product and Organizational Architectures: A Test of the Mirroring Hypothesis” by Alan MacCormack, John Rusnak and Carliss Y. Baldwin found,

Our results have significant managerial implications, in highlighting the impact of organizational design decisions on the technical structure of the artifacts that these organizations subsequently develop.

Or, more simply put: if you want innovative digital products, look for a digital development partner that works in innovative ways…

In software development, take the example of structural and development differences between open-source and closed-source software. Android can be (and is) developed by people all over the world, in a sprawling, loosely-connected community. On the other hand, iOS is developed in a closed, in-house environment. The broad results? iOS works well within its own context but doesn’t always ‘play well with others’; Android is much more flexible in use but arguably less well organized in design terms.

Components & benefits of Conway’s law

The point is, digital development depends on communication, coordination, and cooperation – whether development is effective or ineffective, innovative or unimaginative, depends on how everyone involved works together.

This would suggest that to profit from the principle of Conway’s law, effective digital product design and development benefits from:

  1. Open communication – any limitations, barriers or gatekeepers will impact on product quality.
  2. Aligned goals and incentives – everyone involved is ideally working towards the same end, with the same or equivalent incentives for doing so (the opposite situation leads to people just looking after their own interests).
  3. Autonomous decision-making – those involved need the freedom to make the best decisions for their part of the project (while respecting those aligned goals, of course!) When everything requires consensus, only the safest options are chosen and innovation is reduced.

The ideal digital development partner, according to Conway’s law

If there’s one clear conclusion from Conway’s law, it’s that you need to be careful in your choice of digital development partner. If you’re looking to develop a digital product of some kind (website, mobile app, e-commerce platform… you name it) and you don’t have the necessary expertise in-house, then you need to find the right partner.

Clearly, the quality of communication between you and that partner will be a major influence on the quality of the resulting product. But also, the organizational structure of your partner, and their ways of working and methodologies will also impact on the quality and innovativeness of the results.

In light of Conway’s law, development teams that work well tend to be smaller and more flexible in the way they operate. This enables them to produce iterations of the product quickly, address the design brief and user needs creatively, and be flexible enough to respond to the inevitable changes that occur during the development process.

Looked at like this, Conway’s law is practically an argument in favour of Agile development practices. And that’s something we know about at Boldare… In fact, we feel we can endorse the truth of Conway’s law because our experience in creating highly innovative, often award-winning digital products is based on:

Everyone at Boldare knows what everyone else is doing; almost all communications are via open Slack channels that anyone can join, and the company’s direction, finances, and current performance are no secret. Likewise, we are radically up front with our clients and partners; no surprises or additional costs further down the line!

  • A flexible and empowered organizational structure

We take a holacratic approach to our teams (or ‘circles’, as we call them), adopting a manager-less way of working that allows decisions to be taken by those best-placed to take them.

  • Team functions aligned to the development process

We’re firm believers in viewing the software life cycle as a series of distinct phases, each with its own skills, knowledge and experience requirements when it comes to development. This full cycle product development approach identifies four stages: prototype, minimum viable product (MVP), product-market fit, and scaling. Each team is set up according to the product’s phase, ensuring a tight focus on the product’s specific requirements at its current stage of development.

  • An Agile approach

We are dedicated to Agile software development (usually but not always using the Scrum methodology) with it’s short, goal-focused sprints, open communication, and flexibility.

You might be also interested in the article:

The Three Pillars of Scrum

The Three Pillars of Scrum

Working with Conway’s law

Conway’s law may be 55-years-old this year, but as a basic principle, it anticipated the now-accepted user-centered approach to creating innovative digital products. The structure, distribution, and approach of the organization and people involved in digital product development have a direct impact on the structure and quality of the resulting software. It may sound simplistic to say that digital products are a reflection of the teams that build them, but it’s often literally true!