Imagine that you and another developer are tasked with two parts of the same software.

You meet, discuss how these parts may interface and go off to do work on your own.

In all likelihood, this software will be organized just like the people that produced it,

two components that communicate and agreed upon ways.

Extend this a little bit further.

Now, there are five people.

Two in one group and three in the other.

In all likelihood, one group will split their problem

into two and the other will split their problem in three,

or perhaps a larger group will assign the third person to be concerned with

the communication between groups so that the two layers will each have two components.

That's a situation you see in this diagram.

A study at the Harvard Business School by MacCormack and others in 2007,

showed that looser organizational structures,

such as in open-source projects,

led to more loosely coupled, modular code.

In-house development teams tended toward tighter coupling.

They suggest this difference could be due to conscious choices by

the developers or just a natural consequence

of the environment in which the software is developed.

These examples illustrate Conway's law.

A system will tend to take a form that is congruous to the organization that produced it.

Putting a team together without regard to

Conway's law may lead to unintended consequences for the software architecture.

For example, your team may start out with the intention to

build a highly modular and loosely coupled software system,

but the team did not talk about the interfaces among the components at the time.

However, you all work in the same room at the same office.

The constant communication makes it too easy to bind the components together with

tight coupling because you did not plan the connections between components in advance.

In the end, the code is not as reusable or maintainable as originally intended

because the structures of the work process and

work group did not lead naturally to the desired result.

On the other hand, knowledge of Conway's law can be harnessed

to plan development teams around the desired architecture.

Luckily, many programmers know Conway's law or

intuitively understand it even if they don't know it by name.

If you're putting together a team of developers,

it helps to first plan the architecture that works best for

the system and to organize the team around that architecture.

If you're building a web application, for example,

your architecture is likely to be n-Tier with three tiers.

You could have a team that builds the data back-end,

one team that builds the application logic layer

and one team that builds the presentation tier.

Having some flexibility could also be useful in cases where

implementation of a component is not yet known or may change.

Conway's law implies that extra work may be needed to

provide unified and scalable architectures.

If you have five groups working on five subsystems of a software system,

the software will probably end up being a set of

paired integrations rather than a more extensible architecture.

It would be better to split off some people into a new team whose purpose is

to consolidate and enforce common services across the whole system.

Conway's law is widely known and widely applicable in the software world.

It will help organize effective teams or identify inefficient ones.

Despite its name, it's more of an observation

and could be stretched or broken in some cases.

Even then, it helps to be aware of it and the implications it holds

for putting together your team of developers and your software architecture.

3.3.3 – Relationship to Organizational Structure

Software Architecture

Rencontrer les enseignants