: Shaun Phillips, Thomas Zimmermann, Christian BirdVenue
: 36th International Conference on Software EngineeringDate
: 2014Type of Experiement
: Survey/Multi-Case StudySample Size
: 7Class/Experience Level
: ProfessionalParticipant Selection
: Recruited through contacts in various Microsoft organizationsData Collection Method
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.