Identifying Failure Inducing Developer Pairs within Developer Networks

Author(s): J. Ell
Venue: International Conference on Software Engineering
Date: 2013

Type of Experiement: Case Study


Often in large projects you will find that the code is highly modular and reusable which creates technical dependencies. These dependencies exist between methods or functions that can be used in any location throughout the project. Therefore when changes are made to any given method you may see a “rippling effect” across the rest of the project. When these effects are large they are very likely to cause failures in the system during the project’s lifespan. In observing technical dependencies, analysis on the developer network and developer coordination can be made. The current module based method for predicting success or failure of code changes lacks the ability to provide recommendation for improved coordination other than focusing on tests.
The author explores the following question: “Is it possible to identify pairs of developers whose technical dependencies in code changes statistically relate to bugs?”
The process used to locate these pairs of developer networks utilizes code changes and the call hierarchies effected. This process helps find patterns of developer relationships in successful and failed code changes.
The extract the technical network a network of developers must be created based on method of ownership and those methods call hierarchies effected by code changes. To achieve this developer owner of methods must be identified by performing a Git query. Git queries are also used to determine method call hierarchies (dependencies) . Once the developer owner and technical dependencies are pinpointed code change effects to these hierarchies can be discovered through a method call graph. The final technical network is a diagram composed of owners to code change technical dependencies.
The technical network is then utilized to identify failure inducing Developer pairs using the approach of Sliwerski et al. A failure index (F1) is generated and pairs with the highest F1 value are said to be failure inducing structures inside a project.
The author concludes that the failure inducing developer pairs can be used in prediction of future bus as well as provide coordination recommendations for developers.