1. 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

2. 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. 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.

4. 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.