As collaborative coding environments make it easier to contribute to software projects, the number of developers involved in these projects keeps increasing. Consequently, making it more difficult for code reviewers to deal with harmful contributions. Collaborative environments like GitHub provide a rich source of data on developers' contribution, which can be used to extract information on technical (e.g., developers' experience) and social (e.g., interactions among developers) factors related to developers. Recent studies analyzed the influence of these factors on different activities of the software development. However, there is still little knowledge on the relation between these factors and the introduction of bugs. We present a broader study on relating five technical, two social factors and the introduction of bugs. The results indicate that both technical and social factors present statistically significant relations with the introduction of bugs. Particularly, the developers' habits of not following technical contribution norms are associated with an increase on commit bugginess. Unexpectedly, the presence of tests in commits presents a relation with the increase of commit bugginess. Finally, the developer's experience presents a contradictory relation with the introduction of bugs. But, the analysis of both code complexity and developer's experience may explain this contradiction.
Mockus @cite_19 investigated the organizational factor (e.g, size of the organization, time between releases) relating to the presence of defects in the software. The author found that recent departures from an organization and distributed development are related with commit bugginess. Bernardi @cite_8 studied the influence of developer communication on commit bugginess, finding that developers who introduce bugs have a higher social importance and communicate less between themselves.
@cite_19 @cite_8
2150800057 1984769753 1988510359 2093125667
Developers working on related artifacts often communicate each other to coordinate their changes and to make others aware of their changes. When such a communication does not occur, this could create misunderstanding and cause the introduction of bugs. This paper investigates how the level of communication between committers relates to their proneness to introduce faults. This is done by identifying committers likely responsible of bug-introducing changes, and comparing-through social network measures-characteristics of their communication with the characteristics of other committers. We report results from a study conducted on bugs from Eclipse and Mozilla, indicating that bug-introducing committers have a higher social importance than other committers, although the communication between themselves is significantly lower than for others. Modern software is often developed over many years with hundreds of thousands of commits. Commit metadata is a rich source of social characteristics, including the commit's time of day and the experience and commit frequency of its author. The "bugginess" of a commit is also a critical property of that commit. In this paper, we investigate the correlation between a commit's social characteristics and its "bugginess"; such results can be very useful for software developers and software engineering researchers. For instance, developers or code reviewers might be well-advised to thoroughly verify commits that are more likely to be buggy. In this paper, we study the correlation between a commit's bugginess and the time of day of the commit, the day of week of the commit, and the experience and commit frequency of the commit authors. We survey two widely-used open source projects: the Linux kernel and PostgreSQL. Our main findings include: (1) commits submitted between midnight and 4 AM (referred to as late-night commits) are significantly buggier and commits between 7 AM and noon are less buggy, implying that developers may want to double-check their own latenight commits; (2) daily-committing developers produce less-buggy commits, indicating that we may want to promote the practice of daily-committing developers reviewing other developers' commits; and (3) the bugginess of commits versus day-of-week varies for different software projects. Software teams should follow a well defined goal and keep their work focused. Work fragmentation is bad for efficiency and quality. In this paper we empirically investigate the relationship between the fragmentation of developer contributions and the number of post-release failures. Our approach is to represent developer contributions with a developer-module network that we call contribution network. We use network centrality measures to measure the degree of fragmentation of developer contributions. Fragmentation is determined by the centrality of software modules in the contribution network. Our claim is that central software modules are more likely to be failure-prone than modules located in surrounding areas of the network. We analyze this hypothesis by exploring the network centrality of Microsoft Windows Vista binaries using several network centrality measures as well as linear and logistic regression analysis. In particular, we investigate which centrality measures are significant to predict the probability and number of post-release failures. Results of our experiments show that central modules are more failure-prone than modules located in surrounding areas of the network. Results further confirm that number of authors and number of commits are significant predictors for the probability of post-release failures. For predicting the number of post-release failures the closeness centrality measure is most significant. The key premise of an organization is to allow more efficient production, including production of high quality software. To achieve that, an organization defines roles and reporting relationships. Therefore, changes in organization's structure are likely to affect product's quality. We propose and investigate a relationship between developer-centric measures of organizational change and the probability of customer-reported defects in the context of a large software project. We find that the proximity to an organizational change is significantly associated with reductions in software quality. We also replicate results of several prior studies of software quality supporting findings that code, change, and developer characteristics affect fault-proneness. In contrast to prior studies we find that distributed development decreases quality. Furthermore, recent departures from an organization were associated with increased probability of customer-reported defects, thus demonstrating that in the observed context the organizational change reduces product quality.