Software and engineering
Conway's law
A system's design copies the communication structure of the organisation that built it, so the org chart is an architecture decision.
Melvin Conway, "How Do Committees Invent?", Datamation, April 1968.
Conway's 1968 paper makes one claim: an organisation that designs a system is constrained to produce a design that copies its own communication structure. The mechanism is simple. Two modules can only have a well-designed interface if the two groups building them talk to each other, so the set of designs an organisation can produce is limited to those whose module graph matches its communication graph. Conway puts it as a class of design alternatives that cannot be pursued because the needed communication paths do not exist. He adds a warning about large projects: as a big design organisation fragments, the system's structure records the fragmentation.
Alan MacCormack, John Rusnak and Carliss Baldwin tested this 'mirroring hypothesis' in a Harvard Business School working paper by pairing open source products, built by loosely coupled communities, with commercial products of the same function. They measured propagation cost, the share of a system's files a change can reach through dependencies. In every pair the loosely coupled organisation had produced the more modular product, by up to a factor of eight. In practice it is visible at small scale: a company with a database team, a backend team and a front-end team builds a three-layer system with its seams exactly where the teams meet, and a service that nobody owns takes the shape of whichever team talks to it most.
Thoughtworks put the 'inverse Conway manoeuvre' on its Technology Radar in July 2014: shape the teams to get the architecture you want. It works slowly, because the existing code keeps the old shape until it is rewritten, and it costs the communication the old structure carried. The evidence also has limits. The Harvard sample is five matched pairs, one open source product (Gnumeric) had a propagation cost over 23 percent, far above the other open source products, and the organisational form was inferred from credits files, so the direction of causation is not settled. Treat the law as a constraint to design around, not a theorem to lean on.
Example
In Harvard Business School working paper 08-039 (revised 2011), Alan MacCormack, John Rusnak and Carliss Baldwin compared five matched pairs of software products doing the same job, one from an open source community and one from a commercial firm: GnuCash, AbiWord, Gnumeric, Linux and MySQL against closed products including Solaris, XNU and Berkeley DB, with Linux matched twice. In the financial-management pair the commercial product's propagation cost was 47.1 percent against 7.7 percent for the open source one; Linux 2.6.8 scored 7.4 percent against just over 24 percent for XNU, a kernel of similar size. The open source product was the more modular in all five pairs.
Where it applies
Before drawing a target architecture, draw the org chart and the chat channels; the boundaries you see there are the boundaries you will ship. If you want a shared platform or a shared evaluation harness to exist, give it a team. In an AI product, a 'model team' and an 'app team' that rarely talk tend to produce a prompt-in, text-out interface with no shared evaluation across it.
Think about it
Which seam in your system exists only because two teams did not talk, and what would it take to remove it?
Applied it to something real? Log it.
Test yourselfA company has separate database, backend and front-end teams. What does Conway's law predict about the system they build, and why?
Three layers with interfaces where the teams meet, because a design can only have interfaces where communication paths exist; the system copies the organisation's communication structure.
Related models
- Brooks's lawAdding people to a late software project makes it later: the new hands cost training and communication before they add output.
- Gall's lawA complex system that works grew from a simple system that worked; one designed complex from the start rarely works and cannot be patched into working.
- EmergenceSimple local rules among many parts produce patterns at the level of the whole that no part contains or intends.
- Feedback loopsA system's output feeds back into its input: balancing loops hold a level steady, reinforcing loops make change grow on itself.
Sources and further reading
- Melvin Conway, "How Do Committees Invent?", Datamation (1968), on the author's site
- Alan MacCormack, John Rusnak and Carliss Baldwin, Exploring the Duality between Product and Organizational Architectures: A Test of the "Mirroring" Hypothesis, HBS Working Paper 08-039 (2011 revision)
- Thoughtworks Technology Radar, Inverse Conway Maneuver (2014)