Parallel Changes in Large-Scale Software Development: An Observational Case Study DEWAYNE E. PERRY University of Texas at Austin HARVEY P. SIY Lucent Technologies and LAWRENCE G. VOTTA Motorola, Inc. Greg Holifield

Four Essential Problems in Software Development: [Brooks 1987] Evolution not only have parallel development within each release, Among releases as well. Scale Multiple dimensions of system organization 1[Perry 1996] Distribution of knowledge

Authors’ Three Goals provide a basic understanding of the parallel-change phenomena begin an investigation of a subproblem: interfering changes explore the relationship between parallel changes and the related quality data Three Hypothesis of Relationship between Parallel Changes and Quality Interfering changes are more likely to result in quality problems later in the development than noninterfering changes. Files with significant degrees of parallel changes are likely candidates for code that “decays” overtime. The degree of interference increases this likelihood. Current technology supporting the management of these problems addresses only superficial aspects of these problems.

Methods Toward Each Goal basic observational data on the nature of parallel changes Examine prima facie cases changes to changes changes within the same day summarize available tools that support parallel development

Classical Tools Library-type Systems (check in/out) Newer Systems SCCS [Rochkind 1975] RCS [Tichy 1982], Newer Systems Rational’s ClearCase(R) [Leblang 1994] Adele Configuration Manager [Estublier and Casallas 1994] Traditional Systems Various Branches one file on developer per file “Newer” Systems allow developers to work in parallel on the same file

Classical Tools Integration of Parallel Changes Semantic Conflicts permanent versions temporary versions Semantic Conflicts Logical Completeness Permanent versions are “branches in the product develop-ment path that have their own life cycle” [Mahler 1994]. Temporary problem figuring out how to merge the multiple versions back into a coherent single version

Conclusion —There are multiple levels of parallel development. —The activities within each of these levels cut across common files. —Over the interval of a particular release (I6), the number of files changed by multiple MRs is 60% —though we would expect the degree of awareness of the implications of these changes to be higher than those made within one day of each other —There is a significant correlation between files with a high degree of parallel development and the number of defects