TIL: Small Cohesive Teams Produce Better Code
Today I learned of a paper published by Microsoft back in 2008. They investigated if they could predict software quality (measured through failures or defects) by looking at the structure of the organization that produced it. This is the abstract.
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. In this paper we present a metric scheme to quantify organizational complexity, in relation to the product development process to identify if the metrics impact failure-proneness. In our case study, the organizational metrics when applied to data from Windows Vista were statistically significant predictors of failure-proneness. The precision and recall measures for identifying failure-prone binaries, using the organizational metrics, was significantly higher than using traditional metrics like churn, complexity, coverage, dependencies, and pre-release bug measures that have been used to date to predict failure-proneness. Our results provide empirical evidence that the organizational metrics are related to, and are effective predictors of failure-proneness.
Some of the factors they looked at were the number of overall engineers who contributed code and the cohesiveness of those engineers, as well as the number of overall edits and a number of other contributors. They found that their model predicted software quality better than similar measures like Code Churn or Code Complexity1. I thought it was interesting as it seemed to back up the assertion from Brooks in Mythical Man Month that adding more engineers to a late running project can actually delay it further. The paper references a potential cause as “if there are N engineers who touch a piece of code there needs to be (N*(N-1))/2 theoretical communication paths for the N engineers to communicate between themselves.”
Perhaps the key really is small, cohesive teams with fewer communication paths and therefore fewer chances for misunderstandings.
-
It should be noted, as the authors do, such studies should always be taken with a grain of salt: “Drawing general conclusions from empirical studies in software engineering is difficult because any process depends to a large degree on a potentially large number of relevant context variables”. ↩︎