Influence of developer factors on code quality: a data study

© 2019 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.Automatic source-code inspection tools help to assess, monitor and improve code quality. Since these tools only examine the software project’s codebase, they overlook other possible factors that may impact code quality and the assessment of the technical debt (TD). Our initial hypothesis is that human factors associated with the software developers, like coding expertise, communication skills, and experience in the project have some measurable impact on the code quality. In this exploratory study, we test this hypothesis on two large open source repositories, using TD as a code quality metric and the data that may be inferred from the version control systems. The preliminary results of our statistical analysis suggest that the level of participation of the developers and their experience in the project have a positive correlation with the amount of TD that they introduce. On the contrary, communication skills have barely any impact on TD.Peer ReviewedPostprint (author's final draft

Evaluating the Effectiveness of Code2Vec for Bug Prediction When Considering That Not All Bugs Are the Same

Bug prediction is an area of research focused on predicting where in a software project future bugs will occur. The purpose of bug prediction models is to help companies spend their quality assurance resources more efficiently by prioritizing the testing of the most defect prone entities. Most bug prediction models are only concerned with predicting whether an entity has a bug, or how many bugs an entity will have, which implies that all bugs have the same importance. In reality, bugs can have vastly different origins, impacts, priorities, and costs; therefore, bug prediction models could potentially be improved if they were able to give an indication of which bugs to prioritize based on an organization’s needs. This paper evaluates a possible method for predicting bug attributes related to cost by analyzing over 33,000 bugs from 11 different projects. If bug attributes related to cost can be predicted, then bug prediction models can use the approach to improve the granularity of their results. The cost metrics in this study are bug priority, the experience of the developer who fixed the bug, and the size of the bug fix. First, it is shown that bugs differ along each cost metric, and prioritizing buggy entities along each of these metrics will produce very different results. We then evaluate two methods of predicting cost metrics: traditional deep learning models, and semantic learning models. The results of the analysis found evidence that traditional independent variables show potential as predictors of cost metrics. The semantic learning model was not as successful, but may show more effectiveness in future iterations

An empirical study on developer-related factors characterizing fix-inducing commits

This paper analyzes developer-related factors that could influence the likelihood for a commit to induce a fix. Specifically, we focus on factors that could potentially hinder developers\u27 ability to correctly understand the code components involved in the change to be committed as follows: (i) the coherence of the commit (i.e., how much it is focused on a specific topic); (ii) the experience level of the developer on the files involved in the commit; and (iii) the interfering changes performed by other developers on the files involved in past commits. The results of our study indicate that fix-inducing\u27 commits (i.e., commits that induced a fix) are significantly less coherent than clean\u27 commits (i.e., commits that did not induce a fix). Surprisingly, fix-inducing\u27 commits are performed by more experienced developers; yet, those are the developers performing more complex changes in the system. Finally, fix-inducing\u27 commits have a higher number of past interfering changes as compared with clean\u27 commits. Our empirical study sheds light on previously unexplored factors and presents significant results that can be used to improve approaches for defect prediction. Copyright (c) 2016 John Wiley & Sons, Ltd

What the Smell? An Empirical Investigation on the Distribution and Severity of Test Smells in Open Source Android Applications

The widespread adoption of mobile devices, coupled with the ease of developing mobile-based applications (apps) has created a lucrative and competitive environment for app developers. Solely focusing on app functionality and time-to-market is not enough for developers to ensure the success of their app. Quality attributes exhibited by the app must also be a key focus point; not just at the onset of app development, but throughout its lifetime. The impact analysis of bad programming practices, or code smells, in production code has been the focus of numerous studies in software maintenance. Similar to production code, unit tests are also susceptible to bad programming practices which can have a negative impact not only on the quality of the software system but also on maintenance activities. With the present corpus of studies on test smells primarily on traditional applications, there is a need to fill the void in understanding the deviation of testing guidelines in the mobile environment. Furthermore, there is a need to understand the degree to which test smells are prevalent in mobile apps and the impact of such smells on app maintenance. Hence, the purpose of this research is to: (1) extend the existing set of bad test-code practices by introducing new test smells, (2) provide the software engineering community with an open-source test smell detection tool, and (3) perform a large-scale empirical study on test smell occurrence, distribution, and impact on the maintenance of open-source Android apps. Through multiple experiments, our findings indicate that most Android apps lack an automated verification of their testing mechanisms. As for the apps with existing test suites, they exhibit test smells early on in their lifetime with varying degrees of co-occurrences with different smell types. Our exploration of the relationship between test smells and technical debt proves that test smells are a strong measurement of technical debt. Furthermore, we observed positive correlations between specific smell types and highly changed/buggy test files. Hence, this research demonstrates that test smells can be used as indicators for necessary preventive software maintenance for test suites

An Investigation of the Effects of Merge Conflicts on Collaborative Software Development

Merge conflicts have long plagued software development. With larger and more dispersed teams comes greater risk of developers working on the same code at the same time. While merge conflicts are known to be painful, their exact impact on software is still largely unknown. Are merge conflicts an isolated problem, or are they linked to bigger issues in the code base? This thesis tries to answer this question. The first 2 parts of this thesis look at the correlation between code smells, bugs, and merge conflicts. Our results show that code that is involved in merge conflicts most frequently is more likely to have bugs, or exhibit code smells. To better understand where tool support is lacking, in the 3rd part we investigated how developers resolve merge conflicts. We used a sensemaking approach to analyze qualitative data collected in situ, where participants were working on production software. We found different patterns developers use when resolving merge conflicts, and different areas where they struggled. Our results show that merge conflicts have a real impact on software quality and also show potential avenues for tool improvements. Finally, we propose a way to predict the difficulty of a merge conflict. This can allow developers to plan ahead and set aside time and resources to handle the merge conflict resolution

Investigating the Effects of Design Quality in OSS Projects

Software systems are becoming an essential part of the lives of both individuals and organizations, and as a consequence, these systems are getting bigger and more complex. Because of this, the tasks of maintaining the quality in these complex software systems are becoming increasingly difficult. Furthermore, these systems are subject to constant pressure to add modifications, implementing new features, or regular bug fixing. Due to an often-strict release schedule, developers may not get the chance to design and implement ideal solutions. This can lead to decay in software design and the growth of technical debt, which negatively impacts the overall quality of the software. Design quality plays a vital role in maintaining the quality of software systems. In the past, several studies have shown the impact of design quality on different quality attributes such as bug density, productivity, and maintenance. Researchers also proposed several tools and techniques to improve design quality. Despite efforts by the research community in past years, there are still gaps in our understanding of how does design quality evolves in OSS projects, how projects manage design quality and how does design quality impacts the long-term health of the projects. This thesis proposes a number of large-scale empirical investigations aiming to understand the gaps. In the first part of this thesis, we investigate the evolution of design quality in OSS projects. Researchers used different metrics to measure the project’s design quality. In this thesis, we investigated two different design quality metrics. The first one is code smells, which are the result of poor design or implementation choices. And the second one is entropy, provides an understanding of design quality in terms of flexibility during the enhancement of its functionality. Our results show that design issues build up and design quality (measured by code smells and entropy) degrades over time. As the project grows older and larger, design issues are fixed less and, as a consequence, build up. In the second part, we investigate how OSS projects manage design quality. As design discussion is the primary mechanism for OSS projects to debate, make and document design decisions, we investigated how developers discuss design in the community, how they evolve along with design quality, and what effect they have on the design quality. Our results show that: I) Regardless of different communication channels used for discussion, 89:51% of all design discussions occur in the project mailing list, II) the average number of design discussions decrease; design quality degrade, as the project evolves, and III) the correlation between design discussions and design quality is small. In the third part, we investigate how does design quality impacts day to day activity (such as code merging) as well as long term health of the projects. We find that code with design issues (code smells) are more likely to be involved in merge conflicts. Our results also show that both code smells and entropy have an impact on the long-term health of the project. In this thesis, we use bug-proneness of the codebase as the measurement of the project’s long-term health

Summarizing and measuring development activity

Software developers pursue a wide range of activities as part of their work, and making sense of what they did in a given time frame is far from trivial as evidenced by the large number of awareness and coordination tools that have been developed in recent years. To inform tool design for making sense of the information available about a developer's activity, we conducted an empirical study with 156 GitHub users to investigate what information they would expect in a summary of development activity, how they would measure development activity, and what factors in uence how such activity can be condensed into textual summaries or numbers. We found that unexpected events are as important as expected events in summaries of what a developer did, and that many developers do not believe in measuring development activity. Among the factors that in uence summarization and measurement of development activity, we identified development experience and programming languages.Christoph Treude, Fernando Figueira Filho, Uirá Kulesz

A Closer Look at Real-World Patches

Bug fixing is a time-consuming and tedious task. To reduce the manual efforts in bug fixing, researchers have presented automated approaches to software repair. Unfortunately, recent studies have shown that the state-of-the-art techniques in automated repair tend to generate patches only for a small number of bugs even with quality issues (e.g., incorrect behavior and nonsensical changes). To improve automated program repair (APR) techniques, the community should deepen its knowledge on repair actions from real-world patches since most of the techniques rely on patches written by human developers. Previous investigations on real-world patches are limited to statement level that is not sufficiently fine-grained to build this knowledge. In this work, we contribute to building this knowledge via a systematic and fine-grained study of 16,450 bug fix commits from seven Java open-source projects. We find that there are opportunities for APR techniques to improve their effectiveness by looking at code elements that have not yet been investigated. We also discuss nine insights into tuning automated repair tools. For example, a small number of statement and expression types are recurrently impacted by real-world patches, and expression-level granularity could reduce search space of finding fix ingredients, where previous studies never explored