CONWAY’S COROLLARY

INAM SOOMRO

1. Conway's Law and its History

In 1967, A computer programmer and scientist Melvin Conway wrote and submitted a

paper to Harvard Business Review (HBR) called “How do committees invent” which was

rejected on the basis that Conway “had not proved [the] thesis”. Later on, in April 1968,

the same paper was accepted and published by “Datamation”, a major IT magazine of the

time [Conway 1968]. In 1974, Conway’s assertion was referred as “Conway’s Law” in the

seminal work named “The Mythical-Man-Month” [Brooks 1974] of Fred Brooks. After

the emergence of empirical software engineering, in the past few years, this law has

received a huge amount of attention which would have been helpful to Conway in 1967 to

prove his assertion. The two empirical case studies contained in this report will provide

the evidence to prove the Conway’s Law on the basis of established empirical guidelines

and can be appreciated and used as a touchstone for modern software engineers and

developers. The main idea behind Conway’s paper was:

“Any organization that designs a system (defined broadly) will produce a design whose

structure is a copy of the organization’s communication structure”.

Conway’s assertion was based on the “Proof” of system’s design origin that artifact the

structure. The assertion claim was focused on the initial design of software development,

however the modern observers and practitioners has perceived it to be valid for later

phases as well and conveys the possible corollary of Conway’s Law as:

“A software system whose structure closely matches its organization’s communication

structure works “better” (defined broadly) than a subsystem whose structure differs from

its organization’s communication structure”.

The high-level goals to sustain by any software development company are productivity

and the quality. The first case study will validate the Conway’s Law for productivity of

software and the second case study will validate the Conway’s Law validating the quality

of software in the context of organizational complexity within Microsoft for windows

vista.

2. Conway's law validating the productivity

2.1 Context

Large-Scale software application development requires a rich communication and

coordination between the engineering teams. If the communication and coordination really

plays an important role in software productivity, the organizations are willing to invest to

make the communication and coordination better. In 2006, Marcelo Cataldo et al. [Cataldo

et al. 2006] asked a question, “How much does coordination affect in a large real-world

software project?”, to answer this question, he investigated a large software project for

work dependencies, coordination needs and the time required to complete a single task. A

single unit of work or a request change represented by the project as modification request

(MR) which may be adding a feature, fixing a problem, or performing maintenance. For

completing the MRs, team members often need to coordinate for (i) some of the MRs are

depend on other MRs, an MR to integrate spellchecker to a word processing application

cannot be accomplished before the implementation of MR of dictionary will exemplify

such MRs. (ii) a software application is mostly built from different interdependent

modules; changes made to one module usually affect other modules.

2.2 Methods

Cataldo et al. proposed that when there is a “coordination fit” called “congruence”

between the dependent tasks that developers have and the coordination activities

performed by these developers, it will be easier to complete tasks (MRs). To examine the

coordination between software developers, Cataldo invented four measures of congruence

to observe communication and team characteristics that facilitate communication. The

four measures of coordination indicate the communication structure of the entire

development organization. It includes structural congruence; defines the ease of

coordination between developers, geographical congruence; defines the difficulty of

physical distance between developers to communicate, task congruence; defines

communication via comments on a particular task (MR), IRC communication congruence;

defines coordination between developers via instant messaging (IRC). The author

investigated software project involved 114 developers, split into eight teams distributed

across three locations. Cataldo et al. measured task assignment by looking at which MRs

were completed by each developer and which files were changed to complete it, then

counting the number of times the two files were changed together during the whole

project that represent the interdependence to complete a single MR.

2.3 Results

Cataldo et al. found that the tasks were completed faster when the communication

structure reflected the artifact structure, this is a proof that when the Conway’s Law is

followed, teams are more productive, and Conway’s corollary is true with respect to the

time required to complete tasks. The authors also found that the tasks completed in less

time when MR had a high level of congruence than a similar MR with a low level of

congruence. The most time required by MR reduced was with structural congruence,

followed by geographical congruence working on related tasks. IRC congruence was

better in later releases than in earlier ones.

Thus the developers’ productivity is explored with the relationship of Conway’s corollary

by inspecting how “Congruence” yields to faster task completion.

2.4 Implications

Results from the study are intended to the similar software projects used in this case study.

To enrich the communication, MRs that are dependent on other MRs should be given to

the developers working on same site. It helps to reduce the time to complete a certain MR

when developers are coordinating via MR comments.

3. Conway's Law validating the Quality

3.1 Context

Quality of a software project is an important factor. Defects found in software after their

releases have not only the monetarist effects, but also it brings down the reputation of the

company. In the reference of Conway’s claim and the cost related with defects, Nachi

Nagappan, Brendan Murphy, Vic Basili researched on organizational structure of post-

release defects of windows vista [Nagappan et al. 2008] and found strong relationship

between the two.

3.2 Methods

For the assessment of Conway’s corollary, Nagappan classified each binary as either

failure prone or not failure prone in windows vista based on distinct failures. To observe

organizational complexity, Nagappan, Murphy, and Basili proposed eight metrics for

organizational complexity and inspected the relationship of each metric with failure-

proneness and built a regression model to observe the effect. The eight measures include

number of engineers, defines the total numbers of engineers currently working, Number of

ex-engineers, defines the total number of engineers left the company during development

and after the release of the product, edit frequency, defines the number of time a single

source file has been changed, and depth of master ownership, defines the depth of binary

distribution within the organization, etc. They used data from version control system to

determine changes made to source file. Nagappan, Murphy, and Basili also gathered data

from the company’s organizational chart to see how engineers were related

organizationally and used logistic regression that takes a series of independent variable as

input and outputs the classification. The authors also used post-release defect data to

classify the binaries into failure-prone and not failure-prone. Then they used logistic

regression to determine the relationship between an independent variable (an

organizational metric) and a classification (failure-prone or not). The authors tried to

predict the failure-prone binaries based on the organizational metrics. The standard way to

compare different prediction techniques is to examine, precision, defines how many of the

binaries predicted classifies as failure-prone are actually failure-prone and recall, defines

how many of the binaries that actually are failure prone are predicted to be failure-prone.

3.3 Results

Nagappan, Murphy, and Basili observed that the organizational metrics had a significant

effect on failure, that is, the higher the number of ex-engineers who worked on binary, the

more failure in that binary. This is a clear indication that the organizational complexity is

related to post-release defects, so in the context of windows vista, it is clear that

organizational complexity is strongly related to post-release defects. It confirms that when

communication and coordination reflects the technical artifacts, the software quality is

“better”.

3.4 Implications

In the case of windows vista, you will know better, if the software has bugs by looking at

the organizational structure rather than looking at the code. More organizational

complexity indicates that the structure of the organization is poorly aligned with the

structure of the software system. When developers from different organizations work on

common binary, it tends to be more failure-prone. In the case of engineers leaving

company, binary-specific domain knowledge is lost. A clear owning team may be

appointed to act as a gatekeeper or change reviewer for each change in the binary.

Stabilizing the interfaces of software components early in the development cycle may

mitigate the negative effects of organizational complexity later on.

Bibliography

- Making Software By Andy Oram; Greg Wilsone , Chapter 11. Conway’s Corollary—

Christian Bird.

- [Brooks 1974] Brooks,F.P. 1974. The Mythical Man-Month. Datamation 20(12):44-52

- [Cataldo et al. 2006] Cataldo. M., P.A. Wagstrom, J.D. Herbsleb, and K.M. Carley.

2006. Identification and coordination requirements: Implications for the design of

collaboration and awareness tools. Proceedings of the 20th Conference on computer

supported cooperative work: 353-362.

- [Conway 1968] Conway, M.E. 1968. How do committees invent? Datamation 14(4):

28–31.

[Nagappan et al. 2008] Nagappan, N., B. Murphy, and V. Basili. 2008. The influence

of organizational structure on software quality: An empirical case study. Proceedings

of the 30th

International Conference on Software Engineering: 521–530.