Conway's law

From HandWiki
Revision as of 23:02, 6 February 2024 by AIposter (talk | contribs) (url)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Short description: Adage linking organization and system structure

Conway's law describes the link between communication structure of organizations to the systems they design. It is named after the computer programmer Melvin Conway, who introduced the idea in 1967.[1] His original wording was:[2][3]

[O]rganizations 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

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.

Variations

Eric S. Raymond, an open-source advocate, restated Conway's law in The New Hacker's Dictionary, a reference work based on the Jargon File. The organization of the software and the organization of the software team will be congruent, he said. Summarizing an example in Conway's paper, Raymond wrote:

If you have four groups working on a compiler, you'll get a 4-pass compiler.[4][5]

Raymond further presents Tom Cheatham's amendment of Conway's Law, stated as:

If a group of N persons implements a COBOL compiler, there will be N−1 passes. Someone in the group has to be the manager.[4]

Yourdon and Constantine, in their 1979 book on Structured Design, gave a more strongly stated variation of Conway's Law:

The structure of any system designed by an organization is isomorphic to the structure of the organization.[6]

James O. Coplien and Neil B. Harrison stated in a 2004 book concerned with organizational patterns of Agile software development:

If the parts of an organization (e.g., teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationships between organizations do not reflect the relationships between product parts, then the project will be in trouble ... Therefore: Make sure the organization is compatible with the product architecture.[7]

More recent commentators have noted a corollary - for software projects with a long lifetime of code reuse, such as Microsoft Windows, the structure of the code mirrors not only the communication structure of the organization which created the most recent release, but also the communication structures of every previous team which worked on that code.[8]

There’s also an old car industry joke:[9]

You can see the organization chart of a car company in the dashboard, and also see whether the steering wheel team hates the gear stick team.

Interpretations

The law is, in a strict sense, only about correspondence; it does not state that communication structure is the cause of system structure, merely describes the connection. Different commentators have taken various positions on the direction of causality; that technical design causes the organization to restructure to fit,[10] that the organizational structure dictates the technical design,[11] or both.[12][13][14] Conway's law was intended originally as a sociological observation[citation needed], but many other interpretations are possible. The New Hacker's Dictionary entry uses it in a primarily humorous context,[15] while participants at the 1968 National Symposium on Modular Programming considered it sufficiently serious and universal to dub it 'Conway's Law'.[6] Opinions also vary on the desirability of the phenomenon; some say that the mirroring pattern is a helpful feature of such systems, while other interpretations say it's an undesirable result of organizational bias.[citation needed] Middle positions describe it as a necessary feature of compromise, undesirable in the abstract but necessary to handle human limitations.[8]

Supporting evidence

An example of the impact of Conway's Law can be found in the design of some organization websites. Nigel Bevan stated in a 1997 paper, regarding usability issues in websites: "Organizations often produce web sites with a content and structure which mirrors the internal concerns of the organization rather than the needs of the users of the site."[16]

Evidence in support of Conway's law has been published by a team of Massachusetts Institute of Technology (MIT) and Harvard Business School researchers who, using "the mirroring hypothesis" as an equivalent term for Conway's law, found "strong evidence to support the mirroring hypothesis", and that the "product developed by the loosely-coupled organization is significantly more modular than the product from the tightly-coupled organization". The authors highlight the impact of "organizational design decisions on the technical structure of the artifacts that these organizations subsequently develop".[17]

Additional and likewise supportive case studies of Conway's law have been conducted by Nagappan, Murphy and Basili at the University of Maryland in collaboration with Microsoft,[18] and by Syeed and Hammouda at Tampere University of Technology in Finland.[19]

See also

References

  1. Conway, Melvin. "Conway's Law". http://www.melconway.com/Home/Conways_Law.html. 
  2. Conway, Melvin E. (April 1968). "How do Committees Invent?". Datamation 14 (5): 28–31. http://www.melconway.com/Home/Committees_Paper.html. Retrieved 2019-10-10. "[…] organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.". 
  3. Conway, Melvin (1968). "How do committees invent". Datamation: 28–31. http://www.melconway.com/Home/pdf/committees.pdf. 
  4. 4.0 4.1 Raymond, Eric S. (October 1996). The New Hacker's Dictionary (3rd ed.). Cambridge, Massachusetts: MIT Press. pp. 124. ISBN 978-0-262-68092-9. https://books.google.com/books?id=g80P_4v4QbIC. "Conway's Law: prov. The rule […] originally stated as "If you have four groups working on a compiler, you'll get a 4-pass compiler". […] Tom Cheatham's amendment of Conway's Law: "If a group of N persons implements a COBOL compiler, there will be N-1 passes. Someone in the group has to be the manager."" 
  5. Eric S. Raymond. "Conway's Law". The Jargon File, version 4.4.8. http://catb.org/~esr/jargon/html/C/Conways-Law.html. 
  6. 6.0 6.1 Yourdon, Edward; Constantine, Larry L. (1979). Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design (2nd ed.). Englewood Cliffs, N.J.: Prentice Hall. ISBN 0138544719. OCLC 4503223. https://books.google.com/books?id=zMQmAAAAMAAJ. "Conway's Law: The structure of a system reflects the structure of the organization that built it. Conway's Law has been stated even more strongly: The structure of any system designed by an organization is isomorphic to the structure of the organization." 
  7. Coplien and Harrison (July 2004). Organizational Patterns of Agile Software Development. Pearson Prentice Hall. ISBN 978-0-13-146740-8. 
  8. 8.0 8.1 Muratori, Casey (in en), The Only Unbreakable Law, https://www.youtube.com/watch?v=5IUj1EZwpJY, retrieved 2022-03-21 
  9. "Is Tesla disruptive?" (in en-GB). 2018-09-01. https://www.ben-evans.com/benedictevans/2018/8/29/tesla-software-and-disruption. 
  10. Chandler, A. D. (1977). The Visible Hand: The Managerial Revolution in American Business. Harvard University Press, Cambridge, MA.
  11. Henderson, R. M., & Clark, K. B. (1990). Architectural innovation: The reconfiguration of existing product technologies and the failure of established firms. Administrative science quarterly, 9-30.
  12. Baldwin, C. Y., & Clark, K. B. (2000). Design rules: The power of modularity (Vol. 1). Chapter 7. MIT press. (Chapters 1 and 14 are counted as a descriptive industry study.)
  13. Fixson, S. K., & Park, J. K. (2008). The power of integrality: Linkages between product architecture, innovation, and industry structure. Research Policy, 37(8), 1296-1316.
  14. "The Mirroring Hypothesis: Theory, Evidence and Exceptions", Lyra J. Colfer, Carliss Y. Baldwin https://www.hbs.edu/ris/Publication%20Files/16-124_7ae90679-0ce6-4d72-9e9d-828872c7af49.pdf
  15. Raymond1996
  16. Bevan, Nigel (November 1997). "Usability issues in website design". Proceedings of the Seventh International Conference on Human-Computer Interaction (HCI International '97). 2. San Francisco, California, USA: Elsevier. pp. 803–806. https://experiencelab.typepad.com/files/usability-issues-in-website-design-1.pdf. 
  17. MacCormack, Alan; Rusnak, John; Baldwin, Carliss Y. (2011). "Exploring the Duality between Product and Organizational Architectures: A Test of the Mirroring Hypothesis". SSRN Working Paper Series. doi:10.2139/ssrn.1104745. ISSN 1556-5068. https://dash.harvard.edu/bitstream/handle/1/34403525/maccormack%2Cbaldwin%2Crusnak_exploring-the-duality.pdf. "We find strong evidence to support the mirroring hypothesis. 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. […] Our results have significant managerial implications, in highlighting the impact of organizational design decisions on the technical structure of the artifacts that these organizations subsequently develop.". 
  18. Nagappan, Nachiappan; Murphy, Brendan; Basili, Victor (2008). "The influence of organizational structure on software quality: An empirical case study". Proceedings of the 13th international conference on Software engineering - ICSE '08. New York, New York, USA: ACM Press. pp. 521. doi:10.1145/1368088.1368160. ISBN 9781605580791. 
  19. Syeed, M. M. Mahbubul; Hammouda, Imed (2013). "Socio-technical Congruence in OSS Projects: Exploring Conway's Law in FreeBSD". Open Source Software: Quality Verification. IFIP Advances in Information and Communication Technology. 404. pp. 109–126. doi:10.1007/978-3-642-38928-3_8. ISBN 978-3-642-38927-6. 

Further reading

  • Alan MacCormack, John Rusnak & Carliss Baldwin, 2012, "Exploring the Duality between Product and Organizational Architectures: A Test of the 'Mirroring' Hypothesis," Research Policy 41:1309–1324 [earlier Harvard Business School Working Paper 08-039], see [1] , accessed 9 March 2015.
  • Lise Hvatum & Allan Kelly, Eds., "What do I think about Conway's Law now? Conclusions of a EuroPLoP 2005 Focus Group," European Conference on Pattern Languages of Programs, Kloster Irsee, Germany, January 16, 2006, see [2], addressed 9 March 2015.
  • Lyra Colfer & Carliss Baldwin. "The Mirroring Hypothesis: Theory, Evidence and Exceptions." Harvard Business School Working Paper, No. 16-124, April 2016. (Revised May 2016.) See [3], accessed 2 August 2016.