Andrew Meneely, Pete Rotella, and Laurie Williams. “Does Adding Manpower Also Affect Quality? An Empirical, Longitudinal Analysis.” ESEC/FSE 2011.
With each new developer to a software development team comes a greater challenge to manage the communication, coordination, and knowledge transfer amongst teammates. Fred Brooks discusses this challenge in The Mythical Man-Month by arguing that rapid team expansion can lead to a complex team organization structure. While Brooks focuses on productivity loss as the negative outcome, poor product quality is also a substantial concern. But if team expansion is unavoidable, can any quality impacts be mitigated? Our objective is to guide software engineering managers by empirically analyzing the effects of team size, expansion, and structure on product quality. We performed an empirical, longitudinal case study of a large Cisco networking product over a five year history. Over that time, the team underwent periods of no expansion, steady expansion, and accelerated expansion. Using team-level metrics, we quantified characteristics of team expansion, including team size, expansion rate, expansion acceleration, and modularity with respect to department designations. We examined statistical correlations between our monthly team-level metrics and monthly product-level metrics. Our results indicate that increased team size and linear growth are correlated with later periods of better product quality. However, periods of accelerated team expansion are correlated with later periods of reduced software quality. Furthermore, our linear regression prediction model based on team metrics was able to predict the product’s post-release failure rate within a 95% prediction interval for 38 out of 40 months. Our analysis provides insight for project managers into how the expansion of development teams can impact product quality.
If there’s one “law” of software development that practitioners across the board have heard of, it has to be Brooks’ Law: “adding manpower to a late project makes it later.” This paper by Meneely & Co. provides a good complement to Brooks’ discussions. It does not concern itself with meeting deadlines, as Brooks did, but it explores the correlation between adding people to a team and the posterior quality of the software the team works on.
The paper reports that adding people is correlated with a later increase in software quality, but adding them too quickly (that is, at a faster pace than in previous months) is correlated with a decrease in quality. A greater organizational modularity is also associated with decreased quality.
I confess that I have trouble wrapping my head around the first of these findings. Theoretically, adding people to a project increases its coordination costs, which in turn should impact all metrics of team success negatively, including quality. And yet we have not only Meneely & Co’s findings, but also last year’s Mockus’ report on organizational volatility making the case that more newcomers are not correlated with more defects, which provides support to this finding. One possibility, discussed by Mockus, is that newcomers are assigned easy tasks, and so they can’t really break things too dramatically or in a way that won’t get caught internally in time. Another possibility, particularly plausible in the Cisco data set, is that the product has matured over time—that software quality would go up no matter the team size simply because there’s less new functionality added as time goes on.
In any case, while we get better answers for the underlying mechanisms in the correlation between increasing team sizes and software quality, the best advice seems to be: it’s OK to bring new people to a team (with respect to quality), just don’t do it too quickly.