Thursday, July 12, 2012

Don't touch my code!

If you've worked at any big company, you probably run into the problem that you are not supposed to touch a component owned by someone else. This can be really infuriating, especially if you know what to change and think that the process gets in the way.

Today I came across this paper by Microsoft Research, University of Zurich, and University of California, David, that talks exactly about this: code ownership. And it makes the case, based on prior research and on Windows Vista and Windows 7 development, that code changes by minor contributors are one of the main predictors of code defects.

Don’t Touch My Code! Examining the Effects of Ownership on Software Quality

Some quotes:
Within Microsoft, we have found that when more people work on a binary, it has more failures.
Based on our observations and discussions with project managers, we suspect that when there is no clear point of contact and the contributions to a software component are spread across many developers, there is an increased chance of communication breakdowns, misaligned goals, inconsistent interfaces and semantics, all leading to lower quality.


The authors also mention that sharing the ownership has a substantial communication and coordination costs:
The set of developers that contribute to a component implicitly form a team that has shared knowledge regarding the semantics and design of the component. Coordination is a known problem in software development [16]. In fact, another of the top three problems identified in Curtis' study [10] was "communication and coordination breakdowns." Working in such a group always creates a need for sharing and integrating knowledge across all members [8]. Cataldo et al. showed that communication breakdowns delay tasks [9]. If a member of this team devotes little attention to the team and/or the component, they may not acquire the knowledge required to make changes to the component without error.


The results of our analysis of ownership in both releases of Windows can be interpreted as follows:
1. The number of minor contributors has a strong positive relationship with both pre- and post-release failures even when controlling for metrics such as size, churn, and complexity.
2. Higher levels of ownership for the top contributor to a component results in fewer failures when controlling for the same metrics, but the effect is smaller than the number of minor contributors.
3. Ownership has a stronger relationship with pre-release failures than post-release failures.
4. Measures of ownership and standard code measures show a much smaller relationship to post-release failures in Windows 7


Finally, the goal is that all these findings can be really actionable, so the authors do have recommendations that teams should follow:
For contexts in which strong ownership is practiced or where empirical studies are consistent with our own findings, we make the following recommendations regarding the development process based on our findings:
1. Changes made by minor contributors should be reviewed with more scrutiny. Changes made by minor contributors should be exposed to greater scrutiny than changes made by developers who are experienced with the source for a particular binary. When possible, major contributors should perform these code inspections. If a major contributor cannot perform all inspections, he or she should focus on inspecting changes by minor contributors.
2. Potential minor contributors should communicate desired changes to developers experienced with the respective binary. Often minor contributors to one binary are major contributors to a depending binary. Rather than making a desired change directly, these developers should contact a major contributor and communicate the desired change so that it can be made by someone who has higher levels of expertise.
3. Components with low ownership should be given priority by QA resources. Metrics such as Minor and Ownership should be used in conjunction with source code based metrics to identify those binaries with a high potential for having many post-release failures. When faced with limited resources for quality-control efforts, these binaries should have priority.
Post a Comment