„Gesetz von Conway“ – Versionsunterschied
| [ungesichtete Version] | [ungesichtete Version] |
→Coplien and Harrison's version: Fixed obvious typo |
clean up, typos fixed: etc) → etc.) (2) using AWB |
||
| Zeile 2: | Zeile 2: | ||
'''Conway's Law''' is an [[adage]] named after [[computer]] [[programmer]] [[Melvin Conway]], who introduced the idea in 1968: |
'''Conway's Law''' is an [[adage]] named after [[computer]] [[programmer]] [[Melvin Conway]], who introduced the idea in 1968: |
||
<blockquote> |
<blockquote> |
||
...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.<ref name=Conway>{{ |
...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.<ref name=Conway>{{citation |
||
|last=Conway |
|last=Conway |
||
|first=Melvin E. |
|first=Melvin E. |
||
| Zeile 18: | Zeile 18: | ||
==Examples of Conway's Law== |
==Examples of Conway's Law== |
||
Consider a large system S that a 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). |
Consider a large system S that a 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. |
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 [[United States customary units]] (e.g., inches, feet and pounds) while the other used [[International System of Units|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."<ref>{{ |
A real life example: NASA's [[Mars Climate Orbiter]] crashed because one team used [[United States customary units]] (e.g., inches, feet and pounds) while the other used [[International System of Units|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."<ref>{{citation |
||
|url=http://mars.jpl.nasa.gov/msp98/news/mco990930.html |
|url=http://mars.jpl.nasa.gov/msp98/news/mco990930.html |
||
|title=Mars Climate Orbiter Team Finds Likely Cause of Loss |
|title=Mars Climate Orbiter Team Finds Likely Cause of Loss |
||
|publisher=[[NASA]] |
|publisher=[[NASA]] |
||
|date=30 September |
|date=30 September 1999 |
||
|accessdate=2009-04-05 |
|accessdate=2009-04-05 |
||
}}</ref> |
}}</ref> |
||
| Zeile 32: | Zeile 32: | ||
== Versions of Conway's Law == |
== Versions of Conway's Law == |
||
=== Raymond’s version=== |
=== Raymond’s version=== |
||
"Conway’s Law prov. The rule that organization of the software and the organization of the software team will be congruent; originally stated as ‘If you have four groups working on a compiler, you’ll get a 4-pass compiler’." |
"Conway’s Law prov. The rule that organization of the software and the organization of the software team will be congruent; originally stated as ‘If you have four groups working on a compiler, you’ll get a 4-pass compiler’.".<ref>{{cite book|title=The New Hacker's Dictionary - 3rd Edition|author=Eric S. Raymond|isbn=978-0262680929|month=October|year=1996}}</ref> |
||
=== Coplien and Harrison’s version === |
=== Coplien and Harrison’s version === |
||
"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 relationship between organizations do not reflect the relationships between product parts, then the project will be in trouble. |
"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 relationship between organizations do not reflect the relationships between product parts, then the project will be in trouble. |
||
Version vom 26. September 2011, 09:11 Uhr
Vorlage:Refimprove Conway's Law is an adage named after computer programmer Melvin Conway, who introduced the idea in 1968:
...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.[1]
Although sometimes construed as humorous, Conway's Law was intended as a valid sociological observation. It is based on the reasoning that in order for two separate software modules to interface correctly, the designers and implementers of each module must communicate with each other. Therefore, the interface structure of a software system will reflect the social structure of the organization(s) that produced it.
Examples of Conway's Law
Consider a large system S that a 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 United States customary 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."[2]
Versions of Conway's Law
Raymond’s version
"Conway’s Law prov. The rule that organization of the software and the organization of the software team will be congruent; originally stated as ‘If you have four groups working on a compiler, you’ll get a 4-pass compiler’.".[3]
Coplien and Harrison’s version
"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 relationship 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."[4]
Service industries
Conway's law may extend to the service industries; for example whether train services are run for the convenience of an individual company or for those they connect with (to the benefit of all). A good example is given in Bill Bryson's Notes From a Small Island, where the only train of the day is scheduled to leave exactly two minutes before the bus to the station arrives.
Supporting evidence
There is supporting evidence of 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.
Another case study of Conway's Law can be found on Microsoft Research.
Notes
- ↑ Vorlage:Citation full text
- ↑ Vorlage:Citation
- ↑ Eric S. Raymond: The New Hacker's Dictionary - 3rd Edition. 1996, ISBN 978-0-262-68092-9.
- ↑ James O. Coplien, Neil B. Harrison: Organizational Patterns of Agile Software Development. 2004, ISBN 978-0-13-146740-8.
