Understanding and Improving Software Build Teams

Author(s): Shaun Phillips, Thomas Zimmermann, Christian Bird
Venue: 36th International Conference on Software Engineering
Date: 2014

Type of Experiement: Survey/Multi-Case Study
Sample Size: 7
Class/Experience Level: Professional
Participant Selection: Recruited through contacts in various Microsoft organizations
Data Collection Method: Survey


Build teams manage a product's configuration, compilation, and packaging. As products become larger and more complex, a build process may take hours to complete. The study notes that some products at Microsoft may take up to 6 hours to build. To manage these build processes, build teams are formed. Although build teams started out as a single developer that knew more about the build process than others, many modern corporations are including actual build teams as part of their organization.

To figure out how to best form build teams, the authors interviewed 7 build engineers from Microsoft with significant build experience, surveyed 132 build engineers, and studied a focus group of 8 build engineers. The authors organized their findings into 3 groups: role ambiguity, knowledge sharing, and intergroup dynamics. The studies concluded that build engineers are classified as emergent - subject to the changing environment and are not pre-planned roles. Thus, each build engineer had different assignments. For example, some wrote tests, others did not. This role ambiguity lead to some issues with job satisfaction. Build engineers rely on undocumented knowledge of build experiences from senior engineers. Thus, a team’s effectiveness matches with how effective the senior engineers communicate with newer engineers. In addition, build engineers noted issues working with software engineers due to a misunderstanding of a build engineer’s job and the frequent corner cutting that software engineers take to ensure a product is competed on time.

Based on the study, the authors recommend redefining the role of a build engineer with clear responsibilities to avoid confusion and job dissatisfaction. To increase communication, the authors suggest using a social build tool. Last, make the build process more transparent to software engineers so they understand the reasoning behind the build structure and will be less likely to circumnavigate it.