Conway’s law

Conway’s law describes the link between the communication structure of organizations and the systems those organizations design for their own needs. The law is named after the computer programmer Melvin Conway, who introduced the idea in 1967.

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.

– Melvin E Conway
How Do Committees Invent?

The law is based on the reasoning that in order for a product to function, the authors and designers of its component parts must communicate with each other in order to ensure compatibility between the components. Therefore, the technical structure of a system will reflect the social boundaries of the organizations that produced it, across which communication is more difficult.

In colloquial terms, it means complex products end up "shaped like" the organizational structure they are designed in, or designed for. The law is applied primarily in the field of software architecture, though Conway directed it more broadly and its assumptions and conclusions apply to most technical fields.

Strictly read, the law only asserts a correspondence. It does not claim that communication structure is the cause of system structure. Commentators have read the causality in both directions. Some argue the organization reshapes itself to fit a chosen technical design. Others hold that the organization’s communication pattern dictates the design. Conway himself framed the idea as a sociological observation, and the most defensible reading is that the two structures co-evolve, each constraining the other.

Origin and reception

Conway wrote up the idea as the article How Do Committees Invent?, which was published in the trade journal Datamation in April 1968. The article had been rejected by a previous venue, and Conway has noted that the law was already implicit in his consulting work on the topic. Later that same year, participants at the 1968 National Symposium on Modular Programming took the observation seriously enough to dub it "Conway’s law".

The law reached a wider software audience through Frederick Brooks, who popularized the name in The Mythical Man-Month (1975). Brooks’s own concerns were closely related. His law, that adding people to a late project makes it later, is driven by the same growth in communication overhead that Conway’s law describes. Where Brooks quantified the cost of communication paths, Conway traced their structural consequence in the resulting design.

Several authors have restated the law in stronger form. Edward Yourdon and Larry Constantine, in Structured Design (1979), asserted that "the structure of any system designed by an organization is isomorphic to the structure of the organization". James Coplien and Neil Harrison, in Organizational Patterns of Agile Software Development (2004), turned the observation into a prescription: if the parts of an organization do not reflect the essential parts of the product, the project will be in trouble, so the organization should be made compatible with the product architecture.

Empirical evidence

Academic researchers study the phenomenon under the name the mirroring hypothesis – the prediction that a product’s architecture will mirror the communication structure of the organization that produced it. Evidence has accumulated across several settings.

A team from MIT and Harvard Business School tested the hypothesis directly. MacCormack, Rusnak, and Baldwin (2012) compared products built by loosely and tightly coupled organizations, including the Linux kernel, and found that the product of the loosely coupled organization was significantly more modular. They concluded that organizational design decisions leave a measurable mark on the technical structure of the artifacts those organizations produce.

Nagappan, Murphy, and Basili (2008), working with Microsoft, found that the organizational structure of a development team influenced the quality of the software it produced. Syeed and Hammouda (2013) found congruent results in the FreeBSD open-source project. The evidence is not unanimous – the mirroring hypothesis has documented exceptions, particularly where a single organization deliberately engineers against its own communication grain – but the broad pattern is well supported.

The inverse Conway maneuver

If the organization shapes the architecture, the organization can be reshaped to produce a desired architecture. This is the inverse Conway maneuver – the practice of designing team and communication boundaries first, so that the system that emerges from those teams matches the intended technical design. The term was popularized in the 2010s by consultants at ThoughtWorks, and the idea has become a cornerstone of modern approaches to microservices.

The maneuver is the active counterweight to the law’s passive observation. Rather than accept the architecture that an existing org chart would produce, a group reorganizes so that the boundaries between teams fall where the boundaries between services should fall. Amazon’s "two-pizza team" rule, which keeps teams small enough to be fed by two pizzas, is an early and influential example. The team topologies framework of Skelton and Pais (2019) builds directly on Conway’s law, prescribing four team types and a small set of interaction modes to keep communication structures aligned with architectural intent.

The flip side is a common failure mode. A team that adopts a microservice architecture without changing how it is organized tends to produce a distributed monolith – many deployable units that are coupled as tightly as the teams that own them remain coupled. Conway’s law predicts this exactly. The technical decomposition will not outrun the communication structure for long.

Methods like domain-driven design mitigate the law’s effects from the other direction. By aligning bounded contexts with team boundaries, DDD makes the organizational seams and the model seams coincide, so that the structure the organization would naturally produce is the structure the design calls for.

See also

References

  • Conway, Melvin E. (April 1968). How Do Committees Invent?. Datamation, 14(5), 28-31.
  • Brooks, Frederick P. (1975). The Mythical Man-Month. Addison-Wesley.
  • Yourdon, Edward, and Constantine, Larry L. (1979). Structured Design. Prentice Hall.
  • MacCormack, Alan, Rusnak, John, and Baldwin, Carliss Y. (2012). Exploring the Duality between Product and Organizational Architectures: A Test of the "Mirroring" Hypothesis. Research Policy, 41(8), 1309-1324.
  • Nagappan, Nachiappan, Murphy, Brendan, and Basili, Victor (2008). The influence of organizational structure on software quality: An empirical case study. Proceedings of ICSE '08.
  • Coplien, James O., and Harrison, Neil B. (2004). Organizational Patterns of Agile Software Development. Prentice Hall.
  • Colfer, Lyra, and Baldwin, Carliss Y. (2016). The Mirroring Hypothesis: Theory, Evidence and Exceptions. Harvard Business School Working Paper 16-124.