Conway's Law
From Wikipedia, the free encyclopedia
Conway's Law is an adage named after computer programmer Melvin Conway, who introduced the idea in 1968. It concerns the structure of organizations and the corresponding structure of systems (particularly computer software) designed by those organizations. In various versions, Conway's Law states:
- Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
- If you have four groups working on a compiler, you'll get a 4-pass compiler.
Or more concisely:
- Any piece of software reflects the organizational structure that produced it.
Despite jocular usage and jocular derivative "laws," Conway's law was not intended as a joke or a Zen koan, but as a valid sociological observation. It is a consequence of the fact that two software modules A and B cannot interface correctly with each other unless the designer and implementer of A communicates with the designer and implementer of B. Thus the interface structure of a software system necessarily will show a congruence with the social structure of the organization that produced it.
There is also Cheatham's Amendment to Conway's Law, named after Tom Cheatham.
- 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.
[edit] Examples of Conway's Law
Consider a large system S that the government wants to build. The government hires company X to build system S. Say company X has three engineering groups, E1, E2, and E3 that participate in the project. Conway's law suggests that it is likely that the resultant system will consist of 3 major subsystems (S1, S2, S3), each built by one of the engineering groups. More importantly, the resultant interfaces between the subsystems (S1-S2, S1-S3, etc) will reflect the quality and nature of the real-world interpersonal communications between the respective engineering groups (E1-E2, E1-E3, etc).
Another example: Consider a two-person team of software engineers, A and B. Say A designs and codes a software class X. Later, the team discovers that class X needs some new features. If A adds the features, A is likely to simply expand X to include the new features. If B adds the new features, B may be afraid of breaking X, and so instead will create a new derived class X2 that inherits X's features, and puts the new features in X2. So, in this example, the final design is a reflection of who implemented the functionality.
A real life example: NASA's Mars Climate Orbiter crashed because one team used English units (e.g., inches, feet and pounds) while the other used metric units for a key spacecraft operation. This information was critical to the maneuvers required to place the spacecraft in the proper Mars orbit. "People sometimes make errors," said Dr. Edward Weiler, NASA's Associate Administrator for Space Science. "The problem here was not the error, it was the failure of NASA's systems engineering, and the checks and balances in our processes to detect the error. That's why we lost the spacecraft."
[edit] Corollary of Conway's Law
Conway's Law can be construed as humorous, to the extent that rigid organizations that are not willing to re-organize to generate an optimal design, can end up producing a sub-standard design that merely reflects the pre-existing organization.
But the essence of Conway's Law also applies to flexible organizations that are willing to re-organize to produce an optimal design.
For example, consider a flexible company that is charged with designing a car, and the company does not yet have a car-design organization. The new car-design organization will probably consist of groups that correspond to the major components of a car: engine, body, transmission, interior, electrical, etc.
The essence of Conway's Law applies even in this re-organization situation: the components and interfaces of the resultant car mirror the engineering groups and their interfaces.
And, significantly, any shortcoming with the interpersonal relationships between the engineering groups, may manifest itself in a shortcoming of the resultant design.
[edit] Empirical proof of Conway's Law
There is an empirical proof of the Conway's Law that has been published by a team of Harvard Business School researchers. Their study reveals significant differences in modularity, consistent with a view that distributed teams tend to develop more modular products.
[edit] Another "Conway's Law"
Conway's Law is sometimes reported as a different adage:
- In every organization there is one person who knows exactly what is going on at all times. This person must be fired.
[edit] See also
[edit] External links
- How Do Committees Invent, Conway's original article from Datamation, 1968.
|
||||||||||||||||||||||||||
