Conway's law

The law of Conway is a named after the American computer scientist Melvin Edward Conway observation that the structures of systems by the communication structures of them transposing those organizations are predetermined. It was formulated by Conway in 1968 as follows:

" Organizations which design systems [ ... ] are constrained to produce designs Which are copies of the communication structures of synthesis Organizations. "

"Organizations that model systems [ ... ] are set to models that represent the communication structures of these organizations. "

The law of Conway is based on the premise that interpersonal communication is necessary for the definition of the interfaces between separate software modules. Therefore, the communication structures of the organizations have a large influence on the structures of these interfaces.

Studies

A study by the Harvard Business School came to the conclusion that there is strong evidence for the correctness of the law of Conway. In all of them examined 12 products from 5 different fields of application ( financial management, word processing, spreadsheet, operating system, database system) correlated the coupling of them developing organizations with the modularity of products.

Further studies could also prove a relation between the architecture of a product and the characteristics of it -converting organization:

• A Microsoft Research study calculated from the complexity of the persons entrusted with the development of Microsoft Windows Vista organizational units of Microsoft complexity and error rate of Windows Vista.
• Rebecca M. Henderson and Kim B. Clark were able to demonstrate that product innovations that change the architecture of the product, require a change in the architecture of knowledge and company structure.
• James D. Herbsleb and Rebecca E. Grinter came to the conclusion that the work should be distributed to a modularized system such that the separation of the development of the distribution of the modules corresponds. Conversely, the development should only be divided if the products to be developed (or parts of the product ) are well understood, plans, processes and interfaces established and are stable.

Examples

Suppose a company is tasked with the implementation of a large software system. The company has commissioned three groups of developers, E1, E2 and E3, which cooperate in the project. The law of Conway now states that the developed software system is likely to consist of three major subsystems S1, S2 and S3, which are implemented in a different one development group. More importantly, the interfaces between the subsystems (S1 -S2, S1 - S3, S2 - S3) correspond to the type and quality of interpersonal communication between the respective development groups (E1 -E2, E1 -E3, E2, E3).

The same is true on a smaller scale: Assume that the software developer has the E1 class K1 implemented for the functionality of F1. Later, the functionality should be added to F1 F2 similar functionality. Sets the software developer E1 of this functionality to, it is simply K1 extend the class to enable this functionality. Sets a software developer E2 from another group this functionality to, so he is probably afraid to break the existing functionality, and therefore implement the functionality F2 in a ( sub) class K2. The design of the application is therefore highly depends on who implements the functionality.

Example of system failure

An example of the failure of a system that can be described by the law of Conway, is the crash of the Mars Climate Orbiter. It was caused by the fact that the development team of Lockheed Martin in the navigation software, the Anglo-American system of measurement, the NASA development team, however, used the International System of Units for the calculations of the control of the probe to reach the intended orbit around Mars. From NASA side of the crash was not so much attributed to the error itself, as the failure of control mechanisms.

Similar findings

Frederick P. Brooks offers in his book The Mythical Man Month in the chapter " Why did the ( mythical ) Tower of Babel Fail? " The analogy that despite clear vision, adequate staff, resources and time, as well as mature technology, projects to communication problems and can fail the resulting organizational changes. Brooks also notes that in software development, scheduling or result in functional failures in a lack of communication between the teams.

James O. Coplien and Neil B. Harrison represented in their book Organizational Patterns of Agile Software Development the view that a project would be difficult to implement if the division of it -converting organization (eg teams, departments or divisions ) is not the most important parts of the reacted product, and the relationships between the organizational parts did not meet the relationship between the product parts. That is why it is important to make the organization compatible with the product architecture.

Greenfield approach

To get to the reactant product suitable communication structures, and thereby get under the Law of Conway suitable product modules, proposes Melvin Conway following " greenfield " approach (english clean slate approach) before:

Quotes

Eric S. Raymond, one of the founders of the Open Source Initiative, writes in the New Hacker's Dictionary, the printed version of the Jargon file, that in the development of a compiler by four groups a 4 -pass compiler will come out.