Adrian Schröter

What makes a good bug report

In software development, bug reports provide crucial information to developers. However, these reports widely differ in their quality. We conducted a survey among developers and users of APACHE, ECLIPSE, and MOZILLA to find out what makes a good bug report. The analysis of the 466 responses revealed an information mismatch between what developers need and what users supply. Most developers consider steps to reproduce, stack traces, and test cases as helpful, which are, at the same time, most difficult to provide for users. Such insight is helpful for designing new bug tracking tools that guide users at collecting and providing more helpful information. Our CUEZILLA prototype is such a tool and measures the quality of new bug reports; it also recommends which elements should be added to improve the quality. We trained CUEZILLA on a sample of 289 bug reports, rated by developers as part of the survey. The participants of our survey also provided 175 comments on hurdles in reporting and resolving bugs. Based on these comments, we discuss several recommendations for better bug tracking systems, which should focus on engaging bug reporters, better tool support, and improved handling of bug duplicates.

Predicting build failures using social network analysis on developer communication

A critical factor in work group coordination, communication has been studied extensively. Yet, we are missing objective evidence of the relationship between successful coordination outcome and communication structures. Using data from IBMs Jazz™ project, we study communication structures of development teams with high coordination needs. We conceptualize coordination outcome by the result of their code integration build processes (successful or failed) and study team communication structures with social network measures. Our results indicate that developer communication plays an important role in the quality of software integrations. Although we found that no individual measure could indicate whether a build will fail or succeed, we leveraged the combination of communication structure measures into a predictive model that indicates whether an integration will fail. When used for five project teams, our predictive model yielded recall values between 55% and 75%, and precision values between 50% to 76%.

What Makes a Good Bug Report

In software development, bug reports provide crucial information to developers. However, these reports widely differ in their quality. We conducted a survey among developers and users of APACHE, ECLIPSE, and MOZILLA to find out what makes a good bug report. The analysis of the 466 responses revealed an information mismatch between what developers need and what users supply. Most developers consider steps to reproduce, stack traces, and test cases as helpful, which are, at the same time, most difficult to provide for users. Such insight is helpful for designing new bug tracking tools that guide users at collecting and providing more helpful information. Our CUEZILLA prototype is such a tool and measures the quality of new bug reports; it also recommends which elements should be added to improve the quality. We trained CUEZILLA on a sample of 289 bug reports, rated by developers as part of the survey. The participants of our survey also provided 175 comments on hurdles in reporting and resolving bugs. Based on these comments, we discuss several recommendations for better bug tracking systems, which should focus on engaging bug reporters, better tool support, and improved handling of bug duplicates.

Does Socio-Technical Congruence Have an Effect on Software Build Success? A Study of Coordination in a Software Project

Socio-technical congruence is an approach that measures coordination by examining the alignment between the technical dependencies and the social coordination in the project. We conduct a case study of coordination in the IBM Rational Team Concert project, which consists of 151 developers over seven geographically distributed sites, and expect that high congruence leads to a high probability of successful builds. We examine this relationship by applying two congruence measurements: an unweighted congruence measure from previous literature, and a weighted measure that overcomes limitations of the existing measure. We discover that there is a relationship between socio-technical congruence and build success probability, but only for certain build types, and observe that in some situations, higher congruence actually leads to lower build success rates. We also observe that a large proportion of zero-congruence builds are successful, and that socio-technical gaps in successful builds are larger than gaps in failed builds. Analysis of the social and technical aspects in IBM Rational Team Concert allows us to discuss the effects of congruence on build success. Our findings provide implications with respect to the limits of applicability of socio-technical congruence and suggest further improvements of socio-technical congruence to study coordination.

Do stack traces help developers fix bugs

A widely shared belief in the software engineering community is that stack traces are much sought after by developers to support them in debugging. But limited empirical evidence is available to confirm the value of stack traces to developers. In this paper, we seek to provide such evidence by conducting an empirical study on the usage of stack traces by developers from the ECLIPSE project. Our results provide strong evidence to this effect and also throws light on some of the patterns in bug fixing using stack traces. We expect the findings of our study to further emphasize the importance of adding stack traces to bug reports and that in the future, software vendors will provide more support in their products to help general users make such information available when filing bug reports.

Information Brokers in Requirement-Dependency Social Networks

Requirements interdependencies create technical dependencies among project members that generally belong to different functional groups in an organization, but who need to coordinate activities during processes of requirements change management. Effective knowledge management is needed to disseminate information on requirement changes across teams working on interdependent requirements to avoid mis-interpretations. Social networks are regarded as important in fostering knowledge management, where brokers or gatekeepers have the role of project members facilitating information flow. However, little is known about processes of information flow and brokerage in social networks built around interdependent requirements. In a field study of requirement interdependencies in a large IT manufacturing organization, we found that brokers holding pockets of knowledge have an impact on information flow in requirement-interdependent teams. We discuss a number of patterns of information flow and draw implications for processes of requirements change management.

Teaching students global software engineering skills using distributed scrum

In this paper we describe distributed Scrum augmented with best practices in global software engineering (GSE) as an important paradigm for teaching critical competencies in GSE. We report on a globally distributed project course between the University of Victoria, Canada and Aalto University, Finland. The project-driven course involved 16 students in Canada and 9 students in Finland, divided into three cross-site Scrum teams working on a single large project. To assess learning of GSE competencies we employed a mixed-method approach including 13 post-course interviews, pre-, post-course and iteration questionnaires, observations, recordings of Daily Scrums as well as collection of project asynchronous communication data. Our analysis indicates that the Scrum method, along with supporting collaboration practices and tools, supports the learning of important GSE competencies, such as distributed communication and teamwork, building and maintaining trust, using appropriate collaboration tools, and inter-cultural collaboration.

Teaching a globally distributed project course using Scrum practices

This paper describes the goals, design and initial challenges encountered in teaching a globally distributed software development course in collaboration between the University of Victoria, Canada and Aalto University, Finland. The project-driven collaboration course involved 16 students in Canada and nine students in Finland, divided into three globally distributed Scrum teams working on the same project. The teams worked on extending Agilefant, an open-source backlog management system, in direct interaction with its product owner. The collaborative development is based on the Scrum methodology. We describe how the Scrum methodology was implemented, and adapted to work in a distributed environment, as well as the infrastructure used to support collaboration, e.g. local war-rooms, and multiple communication tools. We conclude the paper with describing initial challenges encountered, including cultural, semester, course and curriculum differences, as well as technical and time-zone issues.

ProxiScientia: toward real-time visualization of task and developer dependencies in collaborating software development teams

This paper introduces ProxiScientia, a visualization tool that provides awareness support to developers, as they engage in collaborative software development activities. ProxiScientia leverages streams of fine-grained events that are generated by team members as they interact with software artifacts in their development environments. The main goal of the tool is to make each developer aware of coordination needs and opportunities as they arise, by depicting ego-centered views of the developers and tasks that most closely impact their work, and showing how they change in real time. In this paper, we illustrate the conceptualization of ProxiScientia and discuss its initial evaluation.

To talk or not to talk: factors that influence communication around changesets

Building tools to help software developers communicate effectively requires a deep understanding of their communication dynamics. To date we do not have good comprehension of why developers talk to each other as a result of some events in the life of their projects, and not of others. This lack of knowledge makes it difficult to design useful communication models and support systems. In this paper, we narrow down the study of communication behaviour to focus on interactions that occur as a result of a particular kind of project event: the submission of a changeset to the project repository. In a case study with the IBM® Rational® Team Concert™ development team we investigate which factors influence developers to request information about a changeset to their product. We identify several such factors, including the development mode in which the team is operating, the background and recent performance of the author of the changeset, and the risk that the changeset poses to the stability of the product. Incorporating these factors into recommender systems may lead to improvements in their performance.