Empirical Software Engineering
As researchers investigate how software gets made, a new empire for empirical research opens up
Life Imitates Code
In 1967, only partly as a wry joke, Melvin Conway coined his eponymous law:
Any organization that designs a system … will produce a design whose structure is a copy of the organization’s communications structure.
In other words, if the people writing a program are divided into four teams, the program they create will have four major parts.
Nachi Nagappan, Christian Bird and others at Microsoft Research evaluated the validity of Conway’s law by examining data collected during the construction of Windows Vista. Vista consists of thousands of interrelated libraries and programs called binaries. When an error occurs, the breakdown can usually be traced to a fault in a single binary or to a breakdown in the interaction between binaries. Nagappan, Bird, and their team used data mining to explore which aspects of software construction correlated with faults. They found that when work occurred in alignment with Conway’s law—that is, when the structure of the team and the structure of the code mirrored each other—code contained fewer bugs, whereas work that crossed team boundaries increased failure-proneness.
Nagappan and his collaborators then used their data to predict failure-? proneness by locating code produced by multiple groups or at the interface of multiple groups. Contrary to digital folklore, they found that geographic separation between team members didn’t have a strong impact on the quality of their work. What did matter was organizational separation: The farther apart team members were in the company organization chart, the greater the number of faults in the software they produced. This result is applied science at its best: It is both surprising and actionable.