Further Investigation of the Survivability of Code Technical Debt Items

Context: Technical Debt (TD) discusses the negative impact of sub-optimal decisions to cope with the need-for-speed in software development. Code Technical Debt Items (TDI) are atomic elements of TD that can be observed in code artefacts. Empirical results on open-source systems demonstrated how code-smells, which are just one type of TDIs, are introduced and "survive" during release cycles. However, little is known about whether the results on the survivability of code-smells hold for other types of code TDIs (i.e., bugs and vulnerabilities) and in industrial settings. Goal: Understanding the survivability of code TDIs by conducting an empirical study analysing two industrial cases and 31 open-source systems from Apache Foundation. Method: We analysed 133,670 code TDIs (35,703 from the industrial systems) detected by SonarQube (in 193,196 commits) to assess their survivability using survivability models. Results: In general, code TDIs tend to remain and linger for long periods in open-source systems, whereas they are removed faster in industrial systems. Code TDIs that survive over a certain threshold tend to remain much longer, which confirms previous results. Our results also suggest that bugs tend to be removed faster, while code smells and vulnerabilities tend to survive longer.Comment: Submitted to the Journal of Software: Evolution and Process (JSME

Evolution of technical debt remediation in Python: A case study on the Apache Software Ecosystem

In recent years, the evolution of software ecosystems and the detection of technical debt received significant attention by researchers from both industry and academia. While a few studies that analyze various aspects of technical debt evolution already exist, to the best of our knowledge, there is no large-scale study that focuses on the remediation of technical debt over time in Python projects -- i.e., one of the most popular programming languages at the moment. In this paper, we analyze the evolution of technical debt in 44 Python open-source software projects belonging to the Apache Software Foundation. We focus on the type and amount of technical debt that is paid back. The study required the mining of over 60K commits, detailed code analysis on 3.7K system versions, and the analysis of almost 43K fixed issues. The findings show that most of the repayment effort goes into testing, documentation, complexity and duplication removal. Moreover, more than half of the Python technical debt in the ecosystem is short-term being repaid in less than two months. In particular, the observations that a minority of rules account for the majority of issues fixed and spent effort, suggest that addressing those kinds of debt in the future is important for research and practice

On the Diffuseness of Code Technical Debt in Java Projects of the Apache Ecosystem

Background. Companies commonly invest major effort into removing, respectively not introducing, technical debt issues detected by static analysis tools such as SonarQube, Cast, or Coverity. These tools classify technical debt issues into categories according to severity, and developers commonly pay attention to not introducing issues with a high level of severity that could generate bugs or make software maintenance more difficult. Objective. In this work, we aim to understand the diffuseness of Technical Debt (TD) issues and the speed with which developers remove them from the code if they introduced such an issue. The goal is to understand which type of TD is more diffused and how much attention is paid by the developers, as well as to investigate whether TD issues with a higher level of severity are resolved faster than those with a lower level of severity. We conducted a case study across 78K commits of 33 Java projects from the Apache Software Foundation Ecosystem to investigate the distribution of 1.4M TD items. Results. TD items introduced into the code are mostly related to code smells (issues that can increase the maintenance effort). Moreover, developers commonly remove the most severe issues faster than less severe ones. However, the time needed to resolve issues increases when the level of severity increases (minor issues are removed faster that blocker ones). Conclusion. One possible answer to the unexpected issue of resolution time might be that severity is not correctly defined by the tools. Another possible answer is that the rules at an intermediate severity level could be the ones that technically require more time to be removed. The classification of TD items, including their severity and type, require thorough investigation from a research point of view.acceptedVersionPeer reviewe