CONWAY’S COROLLARY                                    INAM SOOMRO1. Conways Law and its HistoryIn 1967, A computer program...
such MRs. (ii) a software application is mostly built from different interdependentmodules; changes made to one module usu...
3.2 MethodsFor the assessment of Conway’s corollary, Nagappan classified each binary as eitherfailure prone or not failure...
Bibliography-   Making Software By Andy Oram; Greg Wilsone , Chapter 11. Conway’s Corollary—    Christian Bird.-   [Brooks...
Upcoming SlideShare
Loading in …5

Conway corollary


Published on

Published in: Education, Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Conway corollary

  1. 1. CONWAY’S COROLLARY INAM SOOMRO1. Conways Law and its HistoryIn 1967, A computer programmer and scientist Melvin Conway wrote and submitted apaper to Harvard Business Review (HBR) called “How do committees invent” which wasrejected 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 thetime [Conway 1968]. In 1974, Conway’s assertion was referred as “Conway’s Law” in theseminal work named “The Mythical-Man-Month” [Brooks 1974] of Fred Brooks. Afterthe emergence of empirical software engineering, in the past few years, this law hasreceived a huge amount of attention which would have been helpful to Conway in 1967 toprove his assertion. The two empirical case studies contained in this report will providethe evidence to prove the Conway’s Law on the basis of established empirical guidelinesand can be appreciated and used as a touchstone for modern software engineers anddevelopers. The main idea behind Conway’s paper was:“Any organization that designs a system (defined broadly) will produce a design whosestructure is a copy of the organization’s communication structure”.Conway’s assertion was based on the “Proof” of system’s design origin that artifact thestructure. 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 laterphases as well and conveys the possible corollary of Conway’s Law as:“A software system whose structure closely matches its organization’s communicationstructure works “better” (defined broadly) than a subsystem whose structure differs fromits organization’s communication structure”.The high-level goals to sustain by any software development company are productivityand the quality. The first case study will validate the Conway’s Law for productivity ofsoftware and the second case study will validate the Conway’s Law validating the qualityof software in the context of organizational complexity within Microsoft for windowsvista.2. Conways law validating the productivity2.1 ContextLarge-Scale software application development requires a rich communication andcoordination between the engineering teams. If the communication and coordination reallyplays an important role in software productivity, the organizations are willing to invest tomake the communication and coordination better. In 2006, Marcelo Cataldo et al. [Cataldoet al. 2006] asked a question, “How much does coordination affect in a large real-worldsoftware project?”, to answer this question, he investigated a large software project forwork dependencies, coordination needs and the time required to complete a single task. Asingle 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. Forcompleting the MRs, team members often need to coordinate for (i) some of the MRs aredepend on other MRs, an MR to integrate spellchecker to a word processing applicationcannot be accomplished before the implementation of MR of dictionary will exemplify
  2. 2. such MRs. (ii) a software application is mostly built from different interdependentmodules; changes made to one module usually affect other modules.2.2 MethodsCataldo et al. proposed that when there is a “coordination fit” called “congruence”between the dependent tasks that developers have and the coordination activitiesperformed by these developers, it will be easier to complete tasks (MRs). To examine thecoordination between software developers, Cataldo invented four measures of congruenceto observe communication and team characteristics that facilitate communication. Thefour measures of coordination indicate the communication structure of the entiredevelopment organization. It includes structural congruence; defines the ease ofcoordination between developers, geographical congruence; defines the difficulty ofphysical distance between developers to communicate, task congruence; definescommunication via comments on a particular task (MR), IRC communication congruence;defines coordination between developers via instant messaging (IRC). The authorinvestigated software project involved 114 developers, split into eight teams distributedacross three locations. Cataldo et al. measured task assignment by looking at which MRswere completed by each developer and which files were changed to complete it, thencounting the number of times the two files were changed together during the wholeproject that represent the interdependence to complete a single MR.2.3 ResultsCataldo et al. found that the tasks were completed faster when the communicationstructure reflected the artifact structure, this is a proof that when the Conway’s Law isfollowed, teams are more productive, and Conway’s corollary is true with respect to thetime required to complete tasks. The authors also found that the tasks completed in lesstime when MR had a high level of congruence than a similar MR with a low level ofcongruence. The most time required by MR reduced was with structural congruence,followed by geographical congruence working on related tasks. IRC congruence wasbetter in later releases than in earlier ones.Thus the developers’ productivity is explored with the relationship of Conway’s corollaryby inspecting how “Congruence” yields to faster task completion.2.4 ImplicationsResults 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 tothe developers working on same site. It helps to reduce the time to complete a certain MRwhen developers are coordinating via MR comments.3. Conways Law validating the Quality3.1 ContextQuality of a software project is an important factor. Defects found in software after theirreleases have not only the monetarist effects, but also it brings down the reputation of thecompany. In the reference of Conway’s claim and the cost related with defects, NachiNagappan, Brendan Murphy, Vic Basili researched on organizational structure of post-release defects of windows vista [Nagappan et al. 2008] and found strong relationshipbetween the two.
  3. 3. 3.2 MethodsFor the assessment of Conway’s corollary, Nagappan classified each binary as eitherfailure prone or not failure prone in windows vista based on distinct failures. To observeorganizational complexity, Nagappan, Murphy, and Basili proposed eight metrics fororganizational complexity and inspected the relationship of each metric with failure-proneness and built a regression model to observe the effect. The eight measures includenumber of engineers, defines the total numbers of engineers currently working, Number ofex-engineers, defines the total number of engineers left the company during developmentand after the release of the product, edit frequency, defines the number of time a singlesource file has been changed, and depth of master ownership, defines the depth of binarydistribution within the organization, etc. They used data from version control system todetermine changes made to source file. Nagappan, Murphy, and Basili also gathered datafrom the company’s organizational chart to see how engineers were relatedorganizationally and used logistic regression that takes a series of independent variable asinput and outputs the classification. The authors also used post-release defect data toclassify the binaries into failure-prone and not failure-prone. Then they used logisticregression to determine the relationship between an independent variable (anorganizational metric) and a classification (failure-prone or not). The authors tried topredict the failure-prone binaries based on the organizational metrics. The standard way tocompare different prediction techniques is to examine, precision, defines how many of thebinaries predicted classifies as failure-prone are actually failure-prone and recall, defineshow many of the binaries that actually are failure prone are predicted to be failure-prone.3.3 ResultsNagappan, Murphy, and Basili observed that the organizational metrics had a significanteffect on failure, that is, the higher the number of ex-engineers who worked on binary, themore failure in that binary. This is a clear indication that the organizational complexity isrelated to post-release defects, so in the context of windows vista, it is clear thatorganizational complexity is strongly related to post-release defects. It confirms that whencommunication and coordination reflects the technical artifacts, the software quality is“better”.3.4 ImplicationsIn the case of windows vista, you will know better, if the software has bugs by looking atthe organizational structure rather than looking at the code. More organizationalcomplexity indicates that the structure of the organization is poorly aligned with thestructure of the software system. When developers from different organizations work oncommon binary, it tends to be more failure-prone. In the case of engineers leavingcompany, binary-specific domain knowledge is lost. A clear owning team may beappointed 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 maymitigate the negative effects of organizational complexity later on.
  4. 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.