Harvard Business Review Rejected Melvin Conway’s Paper for Lack of Proof. Its Thesis Became Conway’s Law.

In 1967, Melvin Conway sent Harvard Business Review (HBR) a paper arguing that the systems an organization designs end up copying the way its people communicate — the idea now known as Conway’s law. The magazine turned it down. “HBR rejected it on the grounds that I had not proved my thesis,” Conway later wrote on his website.

So he sent it to Datamation, which he describes as “the major IT magazine at that time.” It ran in April 1968 under the title “How Do Committees Invent?” Seven years later, Fred Brooks cited the paper in his book The Mythical Man-Month and called its thesis “Conway’s Law.” In Conway’s words: “The name stuck.”

Four decades after the rejection, researchers tested the idea on real software. One of the studies came out of Harvard Business School.

Eight people, two compilers

The paper makes its case with a small example involving two languages of the day: COBOL, for business programs, and ALGOL, for mathematical and scientific ones. “A contract research organization had eight people who were to produce a COBOL and an ALGOL compiler,” Conway wrote. “After some initial estimates of difficulty and time, five people were assigned to the COBOL job and three to the ALGOL job. The resulting COBOL compiler ran in five phases, the ALGOL compiler ran in three.”

A phase is one stage of a compiler’s work, handing its output to the next. Five people, five phases. Three people, three phases. Conway’s general point: “the very act of organizing a design team means that certain design decisions have already been made.” His examples went beyond compilers: “Two military services were directed by their Commander-in-Chief to develop a common weapon system to meet their respective needs. After great effort they produced a copy of their organization chart.”

Conway described the link between team and system with a term from mathematics. In his model, a system is a set of subsystems, or nodes, joined by branches along which they communicate. Wherever two nodes are joined, the design groups that built them “must have negotiated and agreed upon” how they connect. “This kind of a structure-preserving relationship between two sets of things is called a homomorphism,” he wrote.

The 1968 text states the thesis this way: “organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.”

What Conway told managers to do about it

The paper’s criterion for managers: “a design effort should be organized according to the need for communication.” Because “the design which occurs first is almost never the best possible,” Conway argued, the prevailing idea of the system may need to change, so “flexibility of organization is important to effective design.” Brooks, summarizing this point in The Mythical Man-Month, wrote that “the organization chart will initially reflect the first system design, which is almost surely not the right one.”

Conway was also wary of large design teams. The number of possible communication paths in an organization, he noted, is “approximately half the square of the number of people,” so doubling a team roughly quadruples the paths. He called for a management philosophy “not based on the assumption that adding manpower simply adds to productivity.” His recommendation: “Ways must be found to reward design managers for keeping their organizations lean and flexible.”

How researchers later tested Conway’s law

In a Harvard Business School working paper, later published in the journal Research Policy in 2012, Alan MacCormack, John Rusnak and Carliss Baldwin compared pairs of software products that did similar jobs. In each pair, one product came from a loosely coupled organization, such as an open-source community of distributed contributors, and the other from a tightly coupled one, such as a commercial team. If Conway was right, the loosely coupled organizations should produce the more modular code. To check, the authors measured each codebase’s “propagation cost”: the average share of the system that a change to one file could affect, directly or through other files.

Their summary: “In all of the pairs we examine, the product developed by the loosely-coupled organization is significantly more modular than the product from the tightly-coupled organization.” In the financial-software pair, a change to one file could reach 7.74% of the open-source GnuCash on average, against 47.14% of a commercial product the authors call MyBooks.

Nachiappan Nagappan and Brendan Murphy of Microsoft Research, with Victor Basili of the University of Maryland, asked a related question about Windows Vista: does an organization’s structure predict the quality of its software? For 3,404 binaries — the compiled files that make up the system — they computed eight measures of the organization behind the code, such as how many engineers had edited each binary and how many of those engineers had left the company. A model built on these measures predicted which binaries would prove failure-prone after release: 86.2% of the binaries it flagged were failure-prone (its precision), and it caught 84.0% of the failure-prone ones (its recall). A model built on code churn, the amount of code changed, scored 78.6% and 79.9%.

Both studies have limits. The Harvard study compared five product pairs; the Vista study covered one operating system at one company. Neither can show cause and effect.

Where popular versions differ from the record

FOLDOC, a long-running online dictionary of computing, says the law is commonly stated as “If you have four groups working on a compiler, you’ll get a 4-pass compiler.” Conway’s actual example had eight people, split five and three, and counted phases rather than passes.

Brooks was not the first to use the name, either. A biography of Larry Constantine published by the IEEE Computer Society, the computing society of the Institute of Electrical and Electronics Engineers, says the law “was named by George Mealy” at the National Symposium on Modular Programming in July 1968, three months after the paper appeared.

Why the first split of the work matters

The compiler example is the part a team can use today. Deciding who works on what often happens early, when the design is least understood, and it is a design decision whether or not anyone calls it one. Conway’s reasoning is that boundaries between groups tend to become interfaces in the system, because that is where people have to negotiate.

That is also why Conway asked for flexible organizations rather than a perfect first plan. In his argument, the first design is almost never the best one, and an organization fixed around it will keep producing it. Who talks to whom on day one is the first draft of the architecture.

Harvard Business Review wanted proof. Four decades later, part of the evidence came from Harvard Business School. The rejected paper had already shown the pattern in miniature: five people, five phases; three people, three phases.

Explore

Stay connected