Conway's Law from 1968 describes how organizational structures influence software architecture design. It states that teams will design systems that mirror their own communication structures. Conway builds on this with examples and logic, explaining how allocation of people to projects will affect the team's output. The conclusions are still relevant today - that system designs will copy an organization's communication structures, and flexibility is important for effective design. The original article predates concepts like refactoring and Brooks' Law on manpower productivity. It is considered foundational for understanding how organizations influence design.

1. The original Conways law 1-May-03
Sidebox - The original Conways law.doc
(c) Allan Kelly Page 1 of 1
The original Conways law
Conway’s Law is often applied software development, a quick search on the web will provide reference
on Wiki’s specialising in patterns and agile development, Jim Coplien has documented it as an
organisation pattern, and it got a few mentions at the ACCU April 2003 conference.
The law normally gets quotes something like:
“If there are n developers writing a compiler it will be an n-pass compiler”
“A GUI program developed by x developers will provide x ways of doing the same operation”
“Align architecture with team structure”
The original article is now over 35 years old but still worth reading. It is quite general in nature giving
examples as diverse as transport systems and the US constitution but does include the compiler
example.
Conway builds up his theory with logic, describing how as organisations allocate people to projects
they will effect the output of the team. He explains how we can understand communication as a graph
with nodes and branches, which will cause the structure of a system to reflect the structure of the
organisation that designed it.
The conclusions are still relevant to system designers today:
“The basic thesis of this article is that organizations which design systems (...) are constrained to
produce designs which are copies of the communication structures of these organizations. ... a
design effort should be structured according to the need for communication.”
This causes problems, which need to be addressed by the organisation:
“Because the design which occurs first is almost never the best possible ... flexibility of
organization is important to effective design.”
As if describing refactoring thirty years before the word was coined wasn’t enough he foreshadows by
over five years Fred Brookes Mythical Man Month and what we know as Brooks Law:
“There is need for a philosophy of system design management which is not based on the
assumption that adding manpower simple adds to productivity.”
Datamation is no longer published but the short article is well worth reading if you can get a copy of
the April 1968 issue.