The Influence of Organizational Structure on Software Quality

Microsoft study (

Often software systems are developed by organizations consisting of many teams of individuals working together. Brooks states in the Mythical Man Month book that product quality is strongly affected by organization structure. Unfortunately there has been little empirical evidence to date to substantiate this assertion.

From the historical perspective, Fred Brooks in his classic book The Mythical Man Month  provides an analogy in the chapter on Why did the (mythical) Tower of Babel Fail? The observation being that, the people had (1) a clear mission; (2) manpower; (3) (raw) materials; (4) time and (5) technology. The project failed because of – communication, and its consequent organization. Brooks further states that in software systems: schedule disasters, functional misfits and system bugs arise from a lack of communication between different teams. Quoting Brooks “The purpose of organization is to reduce the amount of communication and coordination necessary; hence organization is a radical attack on the communication problems…”. In 1968 Conway (M. E. Conway, “How Do Committees Invent?” Datamation, 14(4), pp. 28-31, 1968.) also observed from his study (organizations produce designs which are copies of the communication structures of these organizations) that the flexibility of an organization is important to effective design. He further went on to say that ways must be found to reward design managers for keeping their organizations lean and flexible indicating the importance of organization on design quality. In a similar vein, Parnas ( D. Parnas, “On the Criteria to be Used in Decomposing Systems into Modules”, Communications of the ACM, 15(2), pp. 1053-1058, 1972.) also indicated that a software module is “a responsibility assignment rather than a subprogram” indicating the importance of organizational structure in the software industry.

Herbsleb and Grinter ( J. D. Herbsleb, Grinter, R. E., “Splitting the Organization and Integrating the Code: Conway’s Law Revisited”, Proceedings of International Conference on Software Engineering, pp. 85-95, 1999.) look at Conway’s law from the perspective of global software development. Their paper explores global software development from a team organizational context based on teams working in Germany and UK. They provide
recommendations based on their empirical case study for the associated problems geographically distributed organizations face with respect to communication barriers and coordination mechanisms. They observed the primary barriers to team coordination were lack of unplanned contact; knowing the right person to contact about specific issues; cost of initiating the contact; effective communication and lack of trust.
Further Herbsleb and Mockus (J. D. Herbsleb, Mockus, A., “Formulation and preliminary test of an empirical theory of coordination in software engineering”, Proceedings of European Software Engineering Conference/Foundations in Software Engineering, pp. 138-147, 2003.) formulate and evaluate an empirical theory (of coordination) towards understanding engineering decisions from the viewpoint of coordination within software

Also Mockus et al. (A. Mockus, Fielding, R.T., Herbsleb, J., “Two case studies of open source software development: Apache and Mozilla”, ACM Transactions on Software
Engineering and Methodology, 11(3), pp. 309 – 346, 2002. ) investigate how different individuals across geographical boundaries contribute towards open source projects (Apache and Mozilla). Perry et al. [33] discuss and motivate the need to consider the larger development picture, which encompasses organizational and social as well as technological factors. They discuss quantitatively measuring people factors and report on the result of two experiments, one which is a self-reported diary of developer activities and the
second an observational study of developer activities. These two experiments also were used to asses the efficacy of each technique towards quantifying people factors.

ORGANIZATIONAL METRICS for the purpose of study

1. Number of Engineers (NOE): This is the absolute number of unique engineers who have touched a binary and are still employed by the company.
Implication: The more people who touch the code, the higher the chances of defective code as there is a higher need for coordination amongst the engineers.

2. Number of Ex-Engineers (NOEE): This is the total number of unique engineers who have touched a binary and have left the company as of the release date of the software
system .
Implications: This measure deals with knowledge transfer. If the employee(s) who worked on a piece of code leaves the company then there is a likelihood that the new person taking
over might not be familiar with the design rationale, the reasoning behind certain bug fixes, and information about other stake holders in the code.

3. Edit Frequency (EF): This is the total number times the source code, that makes up the binary, was edited. An edit is when an engineer checks code out of the VCS, alters it and
checks it back in again. This is independent of the number of lines of code altered during the edit.
Implications: This measure serves two purposes. One being that, if a binary had too many edits it could be an indicator of the lack of stability/control in the code from the different
perspectives of reliability, performance etc. , this is even if a small number of engineers where making the majority of the edits. Secondly, it provides a more complete view of the
distribution of the edits: did a single engineer make majority of the edits, or were they widely distributed amongst the engineers?

4. Depth of Master Ownership (DMO): This metric determines the level of ownership of the binary depending on the number of edits done. The organization level of the person whose reporting engineers perform more than 75% of  the rolled up edits is deemed as the DMO. The DMO metric determines the binary owner based on activity on that binary. Implications: The deeper in the tree is the ownership the more focused the activities, communication, and responsibility. A deeper level of ownership indicates less diffusion of activities, a single point of approval/control which should improve intellectual control. If a binary does not have a clear owner (or has a very low DMO at which 75% of the edits toll up) then there could be issues regarding decision-making when performing a risky bug fix, lack of engineers to follow-up if there is an issue, understanding intersecting code dependencies etc.

5. Percentage of Org contributing to development (PO): The ratio of the number of people reporting at the DMO level owner relative to the Master owner org size.
Implications: The lower the percentage the more local is the ownership and contributions to the binary leading to lower coordination/communication overhead across organizations
and improved synchronization amongst individuals, better intellectual control and provide a single point of contact. This metric minimizes the impact of an unbalanced organization,
whereby the DMO may be two levels deep but 90% of the total organization reports into that DMO.

6. Level of Organizational Code Ownership (OCO): The percent of edits from the organization that contains the binary owner or if there is no owner then the organization that made the majority of the edits to that binary.
Implications: The more the development contributions belong to a single organization, the more they share a common culture, focus, and social cohesion. The more diverse the contributors to the code itself, the higher the chances of defective code, e.g., synchronization issues, mismatches, build breaks.

7. Overall Organization Ownership (OOW): This is the ratio of the percentage of people at the DMO level making edits to a binary relative to total engineers editing the binary.
A high value is good.
Implications: As with previous ownership measures the more the activities belong to a single organization, the more they share a common culture, focus, and social cohesion.
Furthermore, the bigger the organizational distance the more chance there is of miscommunication and misunderstanding of goals focus, etc.

8. Organization Intersection Factor (OIF): A measure of the number of different organizations that contribute greater than 10% of edits, as measured at the level of the overall org owners.
Implications: Greater is the OIF the more diffused is the contribution to a binary. This implies a lack of strong ownership from one particular org. This measure is particularly important when a binary has no owner as it identifies how diffused the ownership is across the total organization.


Table 1: Summary of organizational measures Assertion Metric



The more people who touch the code the lower the quality.


A large loss of team members affects the knowledge retention and thus quality


The more edits to components the higher the instability and lower the quality.


The lower level is the ownership the better is the quality.


The more cohesive are the contributors (organizationally) the higher is the quality.


The more cohesive is the contributions (edits) the higher is the quality.


The more the diffused contribution to a binary the lower is the quality.


The more diffused the different organizations contributing code, the lower is the quality.


Ovaj unos je objavljen u Nekategorizirano. Bookmarkirajte stalnu vezu.


Popunite niže tražene podatke ili kliknite na neku od ikona za prijavu: Logo

Ovaj komentar pišete koristeći vaš račun. Odjava /  Izmijeni )

Google+ photo

Ovaj komentar pišete koristeći vaš Google+ račun. Odjava /  Izmijeni )

Twitter picture

Ovaj komentar pišete koristeći vaš Twitter račun. Odjava /  Izmijeni )

Facebook slika

Ovaj komentar pišete koristeći vaš Facebook račun. Odjava /  Izmijeni )


Spajanje na %s