Abstract Context Security issues in Open-Source (OS) software systems emerge from everyday coding activities carried out by developers. As security best practices evolve toward “shift-left” paradigms—emphasizing early and continuous integration of security into the development process—understanding how these issues are introduced and fixed has become increasingly important. Objective Our primary goal is to study the spread and evolution of security issues that lie in the source code of OS Python software systems at commit level. Method We conducted a mining study in which we quantitatively analyzed the commit histories of 361 OS Python software systems, whose repositories were publicly available on GitHub , for a total of 380,931 commits analyzed. To identify security issues at the commit level, we used SonarQube , a popular and widely used both in academic and industrial contexts Static Application Security Testing ( SAST ) tool. Results We observed that security issues are spread in OS Python software systems (on average, there are about 14 security issues per commit) and tend to survive for 11 days and 14 commits. Critical security issues, despite their high severity level, are the most spread and tend to survive the most. Furthermore, we noticed that 55 kinds of security issues—belonging to 62 OWASP Top 10 and CWE security classes—were introduced, and the top six (per number of introductions) are mostly critical and account for 77% of all introduced security issues. Conclusions Python developers need to give utmost importance to security issues, particularly critical ones. To that end, we can suggest developers that use secure coding practices, automated tools, or even DevSecOps to limit/avoid the introduction of security issues into their source code or fix them as soon as possible.

In this paper, we present the preliminary findings from a qualitative study (i.e., semi-structured interviews) on how a Mindfulness-Based Stress Reduction (MBSR) program, carried out in the Software Development (SD) working context, is perceived by the software developers of a multinational company who participated in the MBSR program and by the instructor who led it. MBSR is a deeply personal and experiential practice in helping individuals manage stress, particularly in high-pressure environments such as workplaces, healthcare settings, education, and other demanding professional or personal situations. Although MBSR has been experimented in different working contexts; surprisingly, it has never been studied in the SD working context where there are several stress factors that developers experience (e.g., time pressure and uncertainty about the content of a particular task and its outcome). In this respect, qualitative research can generate valuable insights into the application of MBSR in the SD working context that cannot be captured by standardized quantitative measures. Being MBSR instructors and software developers the key stakeholders in delivering an MBSR program in the SD working context, understanding their first-hand experiences can provide a more detailed picture of the investigated phenomenon. The most important takeaway result of our research can be summarized as follows: despite initial skepticism, the developers recognized personal improvements due to the MBSR practice, though the integration of MBSR techniques in the working context remained challenging.

Most Software Engineering (SE) human-based controlled experiments rely on students as participants, raising concerns about their external validity. Specifically, the realism of results obtained from students and their applicability to the software industry remains in question. In this short paper, we bring further evidence on this controversial point. To do so, we compare 62 students and 42 software professionals on a bug-fixing task on the same Java program. The students were enrolled in a Bachelor’s program in Computer Science, while the professionals were employed by two multinational companies (for one of them, the professionals were from two offices). Some variations in the experimental settings of the two groups (students and professionals) were present. For instance, the experimental environment of the experiment with professionals was more realistic; i.e., they faced some stress factors such as interruptions during the bug-fixing task. Considering the differences between the two groups of participants, the gathered data show that the students outperformed the professionals in fixing bugs. This diverges to some extent from past empirical evidence. Rather than presenting definitive conclusions, our results aim to catalyze the discussion on the use of students in experiments and pave the way for future investigations. Specifically, our results encourage us to examine the complex factors influencing SE tasks, making experiments as more realistic as possible.

GitHub’s dependency graph is a tool that eases Software Composition Analysis (SCA), and it is leveraged not only by other tools or by practitioners in their analyses but also by researchers when conducting studies on open-source projects. However, its potential inaccuracy may seriously harm its applicability and usefulness. This paper quantitatively and qualitatively analyzes the accuracy of GitHub’s dependency graphs for Java and Python projects, how such accuracy has changed over time, and what the likely pitfalls and limitations of the dependency graph are. After creating statistically significant samples of Java and Python projects, we analyzed their dependency graph in two directions, forward (by looking at dependencies), backward (by looking at dependents), and inspected their manifest/lock files. Results indicate that in our sample, dependencies have over 27% of inaccuracy, and dependents up to 10%. Errors depend on several reasons, among others, an oversimplified processing of manifest/lock files by the dependency graph generator. Our results provide (i) guidelines for researchers to understand the threats arising in studies based on the dependency graph and (ii) insights to practitioners and tool builders to enhance their SCA, given the current limitations of the dependency graph. • We show that GitHub dependency graph is inaccurate ( ≃ 20% errors in dependencies and ≃ 10 errors in dependents). • We report a qualitative categorization of dependency graph inaccuracies root causes. • The findings of our research warn about the accuracy of tools and studies leveraging the dependency graph.

Context: Test-Driven Development ( TDD ) is an agile development approach where the writing of unit tests precedes the writing of production code. Some software engineers have been advocating the use of TDD to develop Embedded Systems ( ESs ) despite the lack of empirical evidence on TDD applied to ES development. Objectives: Our overarching objective is to start building knowledge on TDD applied to ES development. Specifically, we investigated: (i) the claimed benefits of TDD ( i.e., increased external quality of ESs and developers’ productivity) and (ii) how developers apply TDD when developing ESs. Method: We conducted two empirical investigations. The former investigation, comprising two experiments, aimed to study the claimed benefits of TDD. To that end, we asked Computer Science (CS) Master’s students to fulfill ES development tasks by using TDD or a non-TDD approach. The latter investigation consisted of an ethnographically-informed study to gain insights into how developers apply TDD when developing ESs. In this study, we involved CS Master’s students, who were observed while fulfilling an ES development task. The participants in the two empirical investigations were different. Results: We found that the external quality of the developed ESs increased when using TDD as compared to a non-TDD approach, while there was not a substantial difference in developers’ productivity. However, TDD is perceived as more difficult to apply, and the development task is deemed more challenging with TDD. Several patterns emerged about how developers approach TDD when developing an ES ( e.g., the participants did not always develop in conformity with TDD). Conclusion: TDD seems to be a promising approach to the development of ESs, even though further research is needed. In this regard, we believe that our results can pave the way for future research with the involvement of software companies and professionals.

Context: A deprecated API ( Application Programming Interface ) is an API that its original developers no longer recommend using. Although deprecated APIs ( i.e., deprecated fields, methods, and classes) are still implemented, they are likely to be removed in future implementations. Consequently, developers are advised against using deprecated APIs in newly written code and are encouraged to update existing code to remove any deprecated API usage. Objective: We aimed to gather preliminary empirical evidence on deprecated API usages in open-source Java applications. Methods: To pursue such a goal, we conducted an exploratory Mining-Software-Repository ( MSR ) study in which we quantitatively analyzed the commit histories of 14 applications whose software projects were top-starred on GitHub. Results: The most important takeaway results of our study can be summarized as follows: (i) deprecated API usages are pretty widespread in the studied software applications; (ii) only in half of these applications, developers remove deprecated API usages as soon as possible; (iii) consuming their own deprecated APIs is a prevalent phenomenon in half of the studied applications; (iv) the introductions and removals of deprecated API usages are mostly due to changes performed by senior contributors; (v) developers mostly introduce and remove deprecated API usages when they are far from publishing a release version; and (vi) the introductions and removals of deprecated API usages are often undocumented in commit messages. Conclusion: The outcomes of our study suggest that developers should better handle deprecated API usages.

A Software Bill of Materials ( SBOM ) formally lists the open-source and proprietary components that constitute a software product, including their licenses, versions, vendors, vulnerabilities, and supply chain relationships. SBOMs enable software producers and consumers to gain visibility into the software supply chain and monitor the risks associated with software security, licensing, and more. This paper presents the results of an exploratory mining study investigating the adoption of SBOMs by open-source software projects. To that end, we mined GitHub and identified 186 public software repositories using SBOM generation tools owned by SPDX and CycloneDX . Although the adoption of SBOMs is low, it is increasing. Moreover, SBOMs are under version control or available in public release versions of less than half the software projects analyzed. Finally, only a limited fraction of SBOMs contain minimum/recommended information, and some SBOMs are also uncompliant with existing SBOM standards. Our study reveals that software producers are paying more attention to SBOMs, but even so, these may be incomplete. We urge software producers to adopt SBOMs and meet the new software supply chain standards. As for researchers, we foster further investigations on adopting SBOMs and their correct use.

In this folklore-confirmation short paper, we present the results of a study on the removal of dead code. We aim to gather evidence on the impact of dead-method removal on the internal structure of source code and the usage of resources such as compilation time and space to store executable code. To that end, we studied 23 open-source Java desktop applications hosted on GitHub. We cleaned up each of these applications from its dead methods to obtain two versions: one with dead methods (i.e., original version) and another one without them (i.e., cleaned version). For each of these applications, we compared its versions (original and cleaned) to determine whether, and to what extent, the removal of dead methods affects the internal structure of source code and the usage of resources. We observed that, after removing dead methods, the internal structure of source code significantly improves, while the time to compile source code significantly diminishes as well as the space to store executable code.

GitHub’s dependency graph shows dependency relationships between repositories. This feature is leveraged by tools such as Dependabot, or GitHub’s feature to export SBOM (Software Bill of Materials) files. Also, it has been used in empirical studies. Inaccuracies in the dependency graph might negatively affect both the effectiveness of tools and the results of the conducted studies. In this paper, we present the results of a mining study to assess the accuracy of GitHub’s dependency graph in Java and Python open-source software projects. In particular, on April 16th, 2023, we randomly sampled 297 software projects developed in Java and 338 developed in Python (all hosted on GitHub), each using GitHub’s dependency graph. Then, we performed three analyses to assess how accurate GitHub’s dependency graph is: (i) backward analysis, focusing on the accuracy of the dependencies of a given repository, as reported in GitHub’s dependency graph; (ii) forward analysis, focusing on the accuracy of the dependents of a given repository, as reported in GitHub’s dependency graph; and (iii) manifest/lock file analysis, focusing on the correspondence between the dependencies reported in the dependency graph of a given repository and what was reported in the corresponding manifest/lock files. The obtained results highlight several inaccuracies in GitHub’s dependency graph, which might affect the output of tools based on GitHub’s dependency graph (e.g., Dependabot and SBOM generators) as well as the outcomes of past empirical studies. We also provide qualitative insights into these inaccuracies and implications for practitioners and researchers.

Peopleware, which includes anything related to the role of people in Software Development (SD), has been arousing an increasing interest from both the software industry and research community. This interest is due to the current economic system that demands high-quality software products with a short time to market, staying on the budget. This exposes software developers to the risk of experiencing stress, burnout, and reduced motivation, leading, in turn, to reduced job performance, low-quality SD-related artifacts, and increased turnover. Mindfulness represents a promising intervention that might let developers do their best at work, limiting or even preventing the previously mentioned negative outcomes. This paper presents MOOD (Mindfulness fOr sOftware Developers), a research project whose overarching goal is to customize a well-known and validated group-based intervention program, Mindfulness-Based Stress Reduction (MBSR), in the context of SD-related tasks and assess whether it helps developers to improve their well-being and performance, as well as the quality of the SD-related artifacts they produce.

MSR4SBOM (Mining Software Repositories for enhanced Software Bills of Materials) is a project whose main goal is to deliver a framework that analyzes the content of software repositories and SBOMs to provide context-sensitive recommendations. The expected outputs are (i) a set of approaches and tools released as open-source projects, making them exploitable in industrial, academic, and open-source contexts; and (ii) replication packages of our empirical studies and repositories of datasets collected while developing, calibrating, and validating the MSR4SBOM approaches and tools.

In this paper, we present the results of a confirmation study on the impact of dead-method removal on the internal structure of source code, time to compile source code, and space to store compilation results (i.e., executable code). To that end, we cleaned up 23 open-source Java desktop applications hosted on GitHub from their dead methods, obtaining two versions: one with dead methods (i.e., original version) and another one without them (i.e., cleaned version). For each of these applications, we compared its versions (original and cleaned) and found that, after removing dead methods, the internal structure of source code significantly improves, while the time to compile source code significantly diminishes as well as the space to store compilation results. We also performed correlation analyses that allowed us to conclude that the more dead methods are removed, the greater the improvement to the internal structure of source code and the less space to store executable code.

A Software Bill of Materials (SBOM) describes, in a structured, machine-readable format, the open-source and proprietary components that constitute a software product, including their licenses, versions, vendors, vulnerabilities, and dependency relationships. SBOMs enable practitioners to gain visibility into the software supply chain and monitor any risks associated with software security, licensing, and more. In this industry paper, we present the findings of 10 semi-structured interviews with practitioners with different roles in six different software companies operating in Italy, some of which being very large multinationals. The gathered information indicates that the adoption of SBOMs is low, yet the attention of the software industry to software supply chain-related challenges is high. A possible reason behind this outcome is that the software industry has limited knowledge of SBOMs and software supply chain regulations. Although some participants showed a growing interest in SBOMs, the Italian software industry seems to respond less promptly to this technology. We plan to use these results and those from past research to design a survey with practitioners to have a complete picture of SBOM usage in the software industry.

Test-Driven Development (TDD) is an agile software development approach. It promotes short cycles, composed of three phases each, to incrementally implement software functionality: Red, Green, and Refactor. In the Red Phase, the TDD developer writes a unit test for a small chunk of functionality not yet implemented and watches the test fail. In the Green Phase, the TDD developer writes production code to make the test pass as quickly as possible. Finally, in the refactor phase, the TDD developer “cleans” written code. In this demo paper, we present GAI4-TDD (Generative Artificial Intelligence for Test-Driven Development), a PyCharm plugin to support the Green Phase of TDD. Specifically, this plugin generates production code from the tests the TDD developer had written in the Red Phase so that the generated code makes these tests pass. Previous studies have shown that TDD can be beneficial not only in the “traditional” software development context but also in the Embedded Systems (ESs) development context. We preliminary assessed GAI4-TDD in the latter context through a laboratory empirical study on three ESs. We observed that in the greater part of the cases, GAI4- TDD generates production code that successfully implements the chunk of functionality required. A video showing GAI4- TDD in action is available at: https://youtu.be/30IDb-6NgS4.

We present the results of an exploratory investigation to obtain preliminary evidence on the use of Test-Driven Development (TDD), an incremental approach to software development where tests are written before production code, to develop Embedded Systems (ESs). Specifically, we conducted two experiments in which we compared TDD with a non-TDD approach in terms of the external quality of ESs and developers’ productivity. In the experiments, we also gathered qualitative data to better understand the investigated phenomenon. We found that the external quality of the implemented solutions increases when using TDD as compared to a non-TDD approach, while there is not a substantial difference with respect to developers’ productivity. However, TDD is perceived as more difficult to apply than a non-TDD approach, and the development task is deemed more challenging with TDD.

Background: Software vulnerabilities are flaws in application source code that can be exploited to cause harm, hence companies must devise strategies to manage them.Aim: We want to understand how software vulnerabilities are managed in a big IT (Information Technology) service and consulting company like NTT Data.Method: We conducted a focus group involving six software professionals working at NTT Data and analyzed the gathered data through a thematic analysis approach.Results: We found that application security standards are defined based on the needs of the clients (i.e., companies that commissioned NTT Data the software to be developed) and the projects’ nature (i.e., the development of greenfield projects vs. maintenance of existing ones). Also, to detect software vulnerabilities, SAST (Static Application Security Testing) tools are mainly used; among these, SonarLint and SonarQube appear to be the de-facto standards for NTT Data. Finally, not all software vulnerabilities are fixed; for example, the presence of some software vulnerabilities is tolerated by the clients, who take on the responsibility of not removing these vulnerabilities.Conclusions: It seems that developers and NTT Data clients are not averse to securing their code. NTT Data follows the application security standards established with their clients. To detect software vulnerabilities, SonarLint and SonarQube appear to be the de-facto standards, so explaining to some extent the increasing attention on these tools by the software engineering research community.

We conducted a large-scale fine-grained empirical study in which we quantitatively analyzed the commit histories of 200 Open-Source (OS) Python software systems, whose software repositories were publicly available on GitHub, for a total of 164,980 commits analyzed. We focused on commits—this is why our study is considered fine-grained—to investigate the spread and evolution of security concerns. To detect security concerns at a commit level, we used SonarQube, a popular Static Application Security Testing (SAST) tool. We found, among other things, that: security concerns are spread in OS Python software systems (on average, about 11 security concerns per commit) and tend to survive more than a couple of weeks and a dozen commits; and critical security concerns, despite their high severity level, are the most spread and tend to survive the most. Also, we found that 47 different kinds of security concerns were introduced into the source code of the studied software systems, and the top eight (per number of introductions) are severe and account for 87% of all introduced security concerns. Python developers should pay more attention to security concerns, especially those critical, and use secure coding practices, automated tools, or even DevSecOps to avoid the introduction of security concerns into their source code or fix them as soon as possible.

A Software Bill of Materials (SBOM) is a complete, formally structured list of all the open-source and proprietary software components present in a software product, including their licenses, versions, and vendors. SBOMs enable software creators and consumers to gain visibility into the software supply chain and monitor any risks associated with security or licensing. Thereby, the United States Government and the European Union have brought SBOMs to the forefront of digital policy. In this paper, we present the results of an exploratory mining study that aims to investigate the adoption of SBOMs by open-source software projects. To that end, we mined GitHub to identify repositories that use SBOM generation tools developed by SPDX and CycloneDX, identifying a total of 186 public repositories adopting SBOMs. We found that the adoption of SBOMs is low, yet it has an increasing trend. Moreover, SBOM files are available in the repository or published release versions in 46% of the software projects analyzed. SBOMs are getting an increasing attention from software creators and consumers. There is a pressing need for organizations to update their software to meet the new standards required for the software supply chain.

Abstract Background.Dead code is a code smell. It can refer to code blocks, fields, methods, etc. that are unused and/or unreachable—e.g., if a method is unused and/or unreachable, it is a dead method. Past research has shown that the presence of dead code in source code harms its comprehensibility and maintainability. Nevertheless, there is still little empirical evidence on the spread of this code smell in the source code of commercial and open-source software applications. Aims.Our goal is to gather, through an exploratory study, empirical evidence on the spread and evolution of dead methods in open-source Java desktop applications. Method.We quantitatively analyzed the commit histories of 23 open-source Java desktop applications, whose software projects were hosted onGitHub. To investigate the spread and evolution of dead methods, we focused on dead methods detected at a commit level. The total number of analyzed commits in our study is 1,587. The perspective of our exploratory study is that of both practitioners and researchers. Results.We can summarize the most important take-away results as follows:(i)dead methods affect open-source Java desktop applications;(ii)dead methods generally survive for a long time before being “buried” or “revived;”(iii)dead methods that are then revived tend to survive less, as compared to dead methods that are then buried;(iv)dead methods are rarely revived; and(v)most dead methods are stillborn, rather than becoming dead later. Given the exploratory nature of our study, we believe that its results will help researchers to conduct more resource- and time-demanding research on dead methods and, in general, on dead code. Conclusions.We can conclude that developers should carefully handle dead code (and thus dead methods) since it is harmful, widespread, rarely revived, and survives for a long time in software applications.

Web apps are built by using a combination of HTML, CSS, and JavaScript. While building modern web apps, it is common practice to make use of third-party libraries and frameworks, as to improve developers’ productivity and code quality. Alongside these benefits, the adoption of such libraries results in the introduction ofJavaScript dead code, i.e., code implementing unused functionalities. The costs for downloading and parsing dead code can negatively contribute to the loading time and resource usage of web apps. The goal of our study is two-fold. First, we presentLacuna, an approach for automatically detecting and eliminating JavaScript dead code from web apps. The proposed approach supports both static and dynamic analyses, it is extensible and can be applied to any JavaScript code base, without imposing constraints on the coding style or on the use of specific JavaScript constructs. Second, by leveraging Lacuna we conduct an experiment to empirically evaluate the run-time overhead of JavaScript dead code in terms of energy consumption, performance, network usage, and resource usage in the context of mobile web apps. We applied Lacuna four times on 30 mobile web apps independently developed by third-party developers, each time eliminating dead code according to a different optimization level provided by Lacuna. Afterward, each different version of the web app is executed on an Android device, while collecting measures to assess the potential run-time overhead caused by dead code. Experimental results, among others, highlight that the removal of JavaScript dead code has a positive impact on the loading time of mobile web apps, while significantly reducing the number of bytes transferred over the network.

Background: Dead code is a code smell. It can refer to code blocks, variables, parameters, fields, methods, classes, etc. that are unused and/or unreachable. Aim: Results from past empirical studies indicate that dead code is widespread in both desktop and web-based software applications. Also, researchers have shown that both comprehensibility and maintainability of source code are negatively affected when dead code is present. Nevertheless, we still know little about maintenance operations involving dead code. Method: We conducted an exploratory empirical study on 13 open-source Java desktop applications, whose software projects were hosted on GitHub, to provide preliminary evidence on whether, and to what extent, developers modify dead code—more specifically, dead methods—when they deal with the maintenance of open-source Java desktop applications. Results: The most important results of our study can be summarized as follows: (i) developers modify dead methods; (ii) dead methods are modified to a different extent as compared to alive methods; (iii) developers spend time modifying dead methods that are removed in subsequent commits; and (iv) developers modify dead methods that are later revived to a different extent as compared to dead methods that are later removed. Conclusions: One of the conclusions of our study is: developers should remove dead methods, whose presence and purpose are not properly documented, to avoid unnecessary modifications to dead methods during the maintenance of software applications.

Background. Test-Driven Development (TDD) is an agile software development practice, which encourages developers to write “quick-and-dirty” production code to make tests pass, and then apply refactoring to “clean” written code. However, previous studies have found that refactoring is not applied as often as the TDD process requires, potentially affecting software quality.

The Software Engineering (SE) research community has been showing an increasing interest in peopleware, which refers to anything that has to do with the role of human factors in software development. Individuals’ personality is one of the human factors that can affect software development. In this paper, we present the results of a preliminary empirical study to understand whether there is a relationship between the personality traits (i.e., openness, conscientiousness, extraversion, agreeableness, and neuroticism) and productivity of undergraduate students in Computer Science (CS), and internal quality of the programs they developed in an implementation task. In our study, we involved 30 (last-year) undergraduate students in CS, who had to implement a series of features. Our results suggest that there are correlation relationships between some personality traits (i.e., conscientiousness, extraversion, and neuroticism) and software quality. As for productivity, we could not find any correlation relationship.

Regression testing wants to prevent that errors, which have already been corrected once, creep back into a system that has been updated. A naïve approach consists of re-running the entire test suite (TS) against the changed version of the software under test (SUT). However, this might result in a time-and resource-consuming process; e.g., when dealing with large and/or complex SUTs and TSs. To avoid this problem, Test Case Selection (TCS) approaches can be used. This kind of approaches build a temporary TS comprising only those test cases (TCs) that are relevant to the changes made to the SUT, so avoiding executing unnecessary TCs. In this paper, we introduce CATTO (Commit Adaptive Tool for Test suite Optimization), a tool implementing a TCS strategy for SUTs written in Java as well as a wrapper to allow developers to use CATTO within IntelliJ IDEA and to execute CATTO just-in-time before committing changes to the repository. We conducted a preliminary evaluation of CATTO on seven open-source Java projects to evaluate the reduction of the test-suite size, the loss of fault-revealing TCs, and the loss of fault-detection capability. The results suggest that CATTO can be of help to developers when performing TCS. The video demo and the documentation of the tool is available at: https://catto-tool.github.io/

Regression testing is a practice that ensures a System Under Test (SUT) still works as expected after changes have been implemented. The simplest approach for regression testing is Retest-all, which consists of re-executing the entire Test Suite (TS) on the changed version of the SUT. Retest-all could be expensive in case a SUT and its TS grow in size and, if resources are insufficient, its application could be impracticable. A Test Suite Reduction (TSR) approach aims to overcome these issues by reducing the size of TSs, while preserving their fault-detection capability. In this paper, we introduce and validate an approach for TSR based on a multi-objective evolutionary algorithm, namely, Non-dominated Sorting Genetic Algorithm II (NSGA-II). This approach seeks to reduce TSs by maximizing both statement coverage and diversity of test cases of the reduced TSs, while minimizing the size of the reduced TSs. We named this approach Genetic Algorithm for teSt SuitE Reduction (GASSER). To assess GASSER, we conducted an experiment on 19 versions of four software systems from a public dataset—i.e. Software-artifact Infrastructure Repository (SIR). We compared GASSER with nine baseline approaches. The comparison was based on the size of the reduced TSs and their fault-detection capability. The most important take-away result is that GASSER, as compared with the baseline approaches, reduces more the size of the TSs with a non-significant effect on their fault-detection capability. The results of our empirical assessment suggest that the application of multi-objective evolutionary algorithms and, in particular, NSGA-II might represent a viable means to deal with TSR.

Background. Dead code is a code smell. It can refer to code blocks, fields, methods, etc. that are unused and/or unreachable. Empirical evidence shows that dead code harms source code comprehensibility and maintainability in software applications. Researchers have gathered little empirical evidence on the spread of dead code in software applications. Moreover, we know little about the role of this code smell during software evolution.

GitHub currently hosts more than 100 million public repositories. This has made it very popular to conduct Mining Software Repositories (MSR) studies. Researchers have been exploiting the information stored in GitHub (e.g., commits, pull requests, or issues) to investigate both developer- and project-related aspects. GitHub provides the REST API to make queries without cloning repositories. In this tool-demo paper, we highlight some issues we noticed when conducting an MSR study on GitHub by using the REST API and present G-Repo: a tool developed to support researchers when tackling these issues able to ease the creation of datasets for MSR studies. Also, we provide a manually-annotated dataset with information about the kind and the (spoken) languages of 1,500 repositories hosted on GitHub. A video showing the functioning of G-Repo is available at: https://youtu.be/mb9CIALBFZk.

Regression testing is an important activity that ensures a System Under Test (SUT) still works as expected after changes. Regression testing can be expensive in case of large Test Suites (TSs). Test Suite Reduction (TSR) approaches speed up regression testing by removing redundant test cases. These approaches can be classified as adequate or inadequate. Adequate approaches reduce TSs so that they completely preserve the test requirements (e.g., statement coverage) of the original TSs. Inadequate approaches produce reduced TSs that only partially preserve test requirements. An inadequate TSR approach is appealing when it leads to a higher reduction in TS size at the expense of a negligible loss in fault-detection capability. We defined an inadequate approach for TSR named GASSER (Genetic Algorithm for teSt SuitE Reduction). It is based on a multi-objective evolutionary algorithm, NSGA-II (Non-dominated Sorting Genetic Algorithm II). GASSER seeks to reduce TSs by maximizing both the statement coverage and diversity of test cases, and minimizing the size of the reduced TSs. We implemented GASSER in a Java prototype of a supporting tool and named it as the approach, namely GASSER. In this tooldemo paper, we present such a tool prototype as well as the results of a preliminary empirical study to assess the validity of both the approach and the tool prototype. A screen-cast of GASSER in action is available at https://youtu.be/20Uf1ugEvAQ.

Abstract In recent years, we have been witnessing a rapid increase of research on exergames—i.e., computer games that require users to move during gameplay as a form of physical activity and rehabilitation. Properly balancing the need to develop an effective exercise activity with the requirements for a smooth interaction with the software system and an engaging game experience is a challenge. Model-driven software engineering enables the fast prototyping of multiple system variants, which can be very useful for exergame development. In this paper, we propose a framework, PhyDSLK, which eases the development process of personalized and engaging Kinect-based exergames for rehabilitation purposes, providing high-level tools that abstract the technical details of using the Kinect sensor and allows developers to focus on the game design and user experience. The system relies on model-driven software engineering technologies and is made of two main components: (i) an authoring environment relying on a domain-specific language to define the exergame model encapsulating the gameplay that the exergame designer has envisioned and (ii) a code generator that transforms the exergame model into executable code. To validate our approach, we performed a preliminary empirical evaluation addressing development effort and usability of the PhyDSLK framework. The results are promising and provide evidence that people with no experience in game development are able to create exergames with different complexity levels in one hour, after a less-than-two-hour training on PhyDSLK. Also, they consider PhyDSLK usable regardless of the exergame complexity.

Background. Regression testing is a practice that ensures a System Under Test (SUT) still works as expected after changes. The simplest regression testing approach is Retest-all, which consists of re-executing the entire Test Suite (TS) on the new version of the SUT. When SUT and its TS grow in size, applying Retest-all could be expensive. Test Suite Reduction (TSR) approaches would allow overcoming the above-mentioned issues by reducing TSs while preserving their fault-detection capability.

Researcher Bias (RB) occurs when researchers influence the results of an empirical study based on their expectations. RB might be due to the use of Questionable Research Practices (QRPs). In research fields like medicine, blinding techniques have been applied to counteract RB. We conducted an explorative qualitative survey to investigate RB in Software Engineering (SE) experiments, with respect to: (i) QRPs potentially leading to RB, (ii) causes behind RB, and (iii) possible actions to counteract RB including blinding techniques. Data collection was based on semi-structured interviews. We interviewed nine active experts in the empirical SE community. We then analyzed the transcripts of these interviews through thematic analysis. We found that some QRPs are acceptable in certain cases. Also, it appears that the presence of RB is perceived in SE and, to counteract RB, a number of solutions have been highlighted: some are intended for SE researchers and others for the boards of SE research outlets.

Noise, defined as an unwanted sound, is one of the most common factors people have to deal with when performing their daily working tasks. Researchers have marginally investigated the effect of noise on software engineers' performance. In this paper, we present the results of two replicated experiments whose main goal was to increase the body of knowledge, by confirming or not the results of the baseline experiments, on the effect of noise while comprehending functional requirements specifications and fixing faults in source code. The results of the replicated experiments suggest that: (i) noise does not significantly affect the comprehension of functional requirements specifications and (ii) noise significantly and negatively affects fixing faults if this task lasts 30 minutes, while it does not have a significant impact if the task lasts 60 minutes. The results of the replications confirm to a large extent those of the baseline experiments and allow us to postulate, as done for the baseline experiments, that fixing faults is more vulnerable to noise than comprehending the specifications of functional requirements.

Test-Driven Development (TDD) is an incremental approach to software development. Despite it is claimed to improve both quality of software and developers’ productivity, the research on the claimed effects of TDD has so far shown inconclusive results. Some researchers have ascribed these inconclusive results to the negative affective states that TDD would provoke. A previous (baseline) experiment has, therefore, studied the affective reactions of (novice) developers—i.e., 29 third-year undergraduates in Computer Science (CS)—when practicing TDD to implement software. To validate the results of the baseline experiment, we conducted a replicated experiment that studies the affective reactions of novice developers when applying TDD to develop software. Developers in the treatment group carried out a development task using TDD, while those in the control group used a non-TDD approach. To measure the affective reactions of developers, we used the Self-Assessment Manikin instrument complemented with a liking dimension. The most important differences between the baseline and replicated experiments are: (i) the kind of novice developers involved in the experiments—third-year vs. second-year undergraduates in CS from two different universities; and (ii) their number—29 vs. 59. The results of the replicated experiment do not show any difference in the affective reactions of novice developers. Instead, the results of the baseline experiment suggest that developers seem to like TDD less as compared to a non-TDD approach and that developers following TDD seem to like implementing code less than the other developers, while testing code seems to make them less happy.

We present a quasi-experiment to investigate whether, and to what extent, sleep deprivation impacts the performance of novice software developers using the agile practice of test-first development (TFD). We recruited 45 undergraduates, and asked them to tackle a programming task. Among the participants, 23 agreed to stay awake the night before carrying out the task, while 22 slept normally. We analyzed the quality (i.e., the functional correctness) of the implementations delivered by the participants in both groups, their engagement in writing source code (i.e., the amount of activities performed in the IDE while tackling the programming task) and ability to apply TFD (i.e., the extent to which a participant is able to apply this practice). By comparing the two groups of participants, we found that a single night of sleep deprivation leads to a reduction of 50 percent in the quality of the implementations. There is notable evidence that the developers' engagement and their prowess to apply TFD are negatively impacted. Our results also show that sleep-deprived developers make more fixes to syntactic mistakes in the source code. We conclude that sleep deprivation has possibly disruptive effects on software development activities. The results open opportunities for improving developers' performance by integrating the study of sleep with other psycho-physiological factors in which the software engineering research community has recently taken an interest in.

Dead code is a bad smell and it appears to be widespread in open-source and commercial software systems. Surprisingly, dead code has received very little empirical attention from the software engineering research community. In this paper, we present a multi-study investigation with an overarching goal to study, from the perspective of researchers and developers, when and why developers introduce dead code, howthey perceive and cope with it, and whether dead code is harmful. To this end, we conducted semi-structured interviews with software professionals and four experiments at the University of Basilicata and the College of William & Mary. The results suggest that it is worth studying dead code not only in the maintenance and evolution phases, where our results suggest that dead code is harmful, but also in the design and implementation phases. Our results motivate future work to develop techniques for detecting and removing dead code and suggest that developers should avoid this smell.

In this study, we collected evidence from empirical studies published over two decades-from 1995 to 2018-to answer the following general research question: "What is the current existing empirical evidence concerning the use of software modeling to support source code maintenance?" We carried out a systematic literature review on research published in relevant journals, as well as conference and workshop proceedings, to investigate various aspects of our general research question. Although there is a common belief that software models are beneficial for source code maintainability, this aspect has been scarcely investigated in the literature and only a few empirical studies have been conducted in an industrial context. Moreover, most of the used models are UML. As so, our study shows that there is a small body of research related to this field.

[Context] The popularity of tools for software quality analysis has increased over the years, with special attention to tools that calculate technical debt based on violations of a set of rules. SonarQube is one of the most used tools and provides an estimation of the time needed to remediate technical debt. However, practitioners are still skeptical about the accuracy of its remediation time estimation. [Objective] In this paper, we analyze the accuracy of SonarQube remediation time on a set of 15 open source Java projects. [Method] We designed and conducted a case study where we asked 65 novice developers to remove rule violations and reduce the technical debt of 15 projects. [Results] The results point out that SonarQube remediation time, compared to the actual time for reducing technical debt, is generally overestimated, and that the most accurate estimation relates to code smells, while the least accurate concerns bugs. [Conclusions] Practitioners and researchers could benefit from the results of this work to understand up to which extent technical debt is overestimated and have a more accurate estimation of the remediation time.?

Background: Noise, defined as an unwanted sound, is one of the commonest factors that could affect people's performance in their daily work activities. The software engineering research community has marginally investigated the effects of noise on software engineers' performance.

Background. Regression testing is conducted after changes are made to a system in order to ensure that these changes did not alter its expected behavior. The problem with regression testing is that it can require too much time and/or too many resources. This is why researchers have defined a number of regression testing approaches. Among these, Test Suite Reduction (TSR) approaches reduce the size of the original test suites, while preserving their capability to detect faults. TSR approaches can be classified as adequate or inadequate. Adequate approaches reduce test suites so that they completely preserve the test requirements (e.g., statement coverage) of the original test suite, while inadequate ones produce reduced test suites that partially preserve these test requirements.

Background: Test-Driven Development (TDD) is an agile software development practice, which is claimed to boost both external quality of software products and developers' productivity.

Rapid Type Analysis (RTA) is an algorithm for call graph construction, which is known to be fast and to well approximate virtual method calls. In this paper, we explore its use in the context of refactoring, namely we defined an approach that relies on RTA for the detection of the dead method smell in Java code. We implemented this approach in a prototype of supporting tool we named Dead Code Finder (DCF). We empirically assessed DCF (and the underlying approach) through an experiment on four open-source Java desktop application. We compared DCF with three baseline tools. The results indicate that DCF outperforms these baselines in terms of accuracy of the detected dead methods.

Dead code is a bad smell. It is conjectured to be harmful and it appears to be also a common phenomenon in software systems. Surprisingly, dead code has received little empirical attention from the software engineering research community. This post-doctoral track paper shows the main results of a multi-study investigation into dead code with an overarching goal to study when and why developers introduce dead code, how they perceive and cope with it, and whether dead code is harmful. This investigation is composed of semi-structured interviews with software professionals and four experiments at the University of Basilicata and the College of William & Mary. The results suggest that it is worth studying dead code not only in maintenance and evolution phases, where the results suggest that its presence is detrimental to developers, but also in design and implementation phases, where source code is born dead because developers consider dead code as a sort of reuse means. The results also foster the development of tools for detecting dead code. In this respect, two approaches were proposed and then implemented in two prototypes of supporting tool.

Regression testing is an important activity that can be expensive (e.g., for large test suites). Test suite reduction approaches speed up regression testing by removing redundant test cases. These approaches can be classified as adequate or inadequate. Adequate approaches reduce test suites so that they completely preserve the test requirements (e.g., code coverage) of the original test suites. Inadequate approaches produce reduced test suites that only partially preserve the test requirements. An inadequate approach is appealing when it leads to a greater reduction in test suite size at the expense of a small loss in fault-detection capability. We investigate a clustering-based approach for inadequate test suite reduction and compare it with well-known adequate approaches. Our investigation is founded on a public dataset and allows an exploration of trade-offs in test suite reduction. Results help a more informed decision, using guidelines defined in this research, to balance size, coverage, and fault-detection loss of reduced test suites when using clustering.

We carried out a family of controlled experiments to investigate whether the use of abbreviated identifier names, with respect to full-word identifier names, affects fault fixing in C and Java source code. This family consists of an original (or baseline) controlled experiment and three replications. We involved 100 participants with different backgrounds and experiences in total. Overall results suggested that there is no difference in terms of effort, effectiveness, and efficiency to fix faults, when source code contains either only abbreviated or only full-word identifier names. We also conducted a qualitative study to understand the values, beliefs, and assumptions that inform and shape fault fixing when identifier names are either abbreviated or full-word. We involved in this qualitative study six professional developers with 1--3 years of work experience. A number of insights emerged from this qualitative study and can be considered a useful complement to the quantitative results from our family of experiments. One of the most interesting insights is that developers, when working on source code with abbreviated identifier names, adopt a more methodical approach to identify and fix faults by extending their focus point and only in a few cases do they expand abbreviated identifiers.

Context: Test-driven development (TDD) is an agile practice claimed to improve the quality of a software product, as well as the productivity of its developers. A previous study (i.e., baseline experiment) at the University of Oulu (Finland) compared TDD to a test-last development (TLD) approach through a randomized controlled trial. The results failed to support the claims. Goal: We want to validate the original study results by replicating it at the University of Basilicata (Italy), using a different design. Method: We replicated the baseline experiment, using a crossover design, with 21 graduate students. We kept the settings and context as close as possible to the baseline experiment. In order to limit researchers bias, we involved two other sites (UPM, Spain, and Brunel, UK) to conduct blind analysis of the data. Results: The Kruskal-Wallis tests did not show any significant difference between TDD and TLD in terms of testing effort (p-value = .27), external code quality (p-value = .82), and developers' productivity (p-value = .83). Nevertheless, our data revealed a difference based on the order in which TDD and TLD were applied, though no carry over effect. Conclusions: We verify the baseline study results, yet our results raises concerns regarding the selection of experimental objects, particularly with respect to their interaction with the order in which of treatments are applied.

In this paper, we present the results of a controlled experiment conducted to assess whether the presence of unreachable methods in source code affects source code comprehensibility and modifiability. A total of 47 undergraduate students at the University of Basilicata participated in this experiment. We divided the participants in two groups. The participants in the first group were asked to comprehend code base containing unreachable methods and implement five change requests in that code base. The participants in the second group were asked to accomplish exactly the same tasks as the participants in the first group, however, the source code provided to them did not contain any unreachable methods. The results of the study indicate that code comprehensibility is significantly higher when source code does not contain unreachable methods. However, we did not observe a statistically significant difference for code modifiability. From these results, we distill lessons and implications for practitioners as well as possible avenues for further research.

With object-oriented programming languages (e.g., Java or C#), the identification of unreachable source code may be very complex especially when working at method level. To deal with the detection of unreachable methods, we have defined an approach named DUM: Detecting Unreachable Methods. We implemented a prototype of a supporting software we named DUM-Tool. It works on Java byte-code and detects unreachable methods by traversing a graph-based representation of a subject software.

We propose an approach that leverages lexical information and fuzzy clustering to reduce the number of the design pattern instances that existing approaches based on structural information (i.e., navigating the dependencies among software elements) erroneously recover in source code. To assess the effectiveness of the techniques, we present the results of a case study conducted on four open source software systems implemented in java. The data analysis indicates that the use of lexical information and fuzzy clustering improves the correctness of the results achieved by existing design pattern recovery approaches based on structural information, while preserving the number of design pattern instances correctly identified.