-The topic of technical debt has gained significant attention from researchers in recent years since its management has significant impact of software development. Several studies that analyze technical debt evolution from different perspectives; however since most of these studies are done for Java very little is known about the evolution of technical debt in software ecosystems consisting of projects written in other languages. In this paper we run a study across nine Python open-source software projects belonging to the Apache Software Foundation to investigate the amount of technical debt that is paid back. To measure technical debt we use one of the standard tools in industry: SonarQube. We investigate the impact of using the 28 default rules of SonarQube for Python versus using an extended set of 208 rules to detect instances of technical debt. Index Terms-Software Evolution, Technical Debt, Software Ecosystems II. STUDY DESIGN
Technical debt is a metaphor introduced by Ward
Cunningham to explain the unavoidable interests developer pay while
getting the short-term benefits [
There have been several studies that analyzed technical debt
for developing techniques and tools to detect specific types of
technical debt, such as code smells [
Olbrich et al. [
Software ecosystems are groups of projects that co-evolve 2) What is the fixing prevalence of different issue types?
together in the same environment [
However, to the best of our knowledge, there is no study Table 1 shows the nine projects that are left after applying
focuses on technical debt evolution in a Python ecosystem. these inclusion criteria:
Given the pre-eminence of the Python programming language
at the current moment and the lack of technical debt studies
for systems written in the language, we decide to extend the
previous work of Digkas which analyzed the Java projects
from the Apache ecosystem [
Various techniques have been proposed for detecting technical debt. However, since our work does not focus on the detection aspect, we use SonarQube, a third party tool for this purpose. The tool is one of the most popular industrial tools for source code technical debt measurement and reporting and has been used also in the study of the Java systems in the Apache ecosystem.
The goal of our study is to investigate the types of issues that have been fixed during the evolution of Python projects in the Apache ecosystem and the differences between Java and Python, also comparing the types of technical debt between default rules and extended rules (rules for Python debt that must be manually enabled in SonarQube). To this end, we ask two research questions:
TABLE I
SELECTED PROJECTS
To study the evolution of a large number of systems over an extended period, one must make a trade-off between the granularity of the analysis and the feasibility of the analysis (e.g. analyzing all the versions of all the nine selected systems with SonarQube could easily take many months since the tool has no possibility of performing an incremental analysis, but instead, with every commit the system is fully analyzed as a whole). In this study, we analyze weekly versions of each project.
Figure 1 shows the main steps of the data extraction process that we follow in this work: 1) We clone the GitHub repositories of the Python projects in the Apache Ecosystem and analyze the version repository of all the cloned systems 2) We use the two criteria of size and evolution to select Python projects from the Apache ecosystem. We are left with 9 projects. 3) We analyze the entire change history of each project with a weekly resolution by using SonarQube with the default rules (28 rules) 4) We also analyze the history of every project a second time with an extended set of all the possible rules for Python (208 rules).
In this context we want to study the evolution of technical debt fixes.
Analyzing multiple versions of a project with SonarQube is a very time consuming activity, since SonarQube can not reuse results from the analysis of a previous version, so the time required for analysis is proportional to the number of versions that are being analyzed. This slows down the speed with which the analysis can be done. This is why in this remainder of this paper we only look at one project: qpid-python but we plan to update the report as the results from the other systems are flowing in.
A. What is the difference of technical debt types between default rules and extend rules?(RQ1)
When we used the extra plugins of SonarQube and added all the corresponding rules, the number of rules that appear both in Python and Java increased to 27. Thus, using the SonarQube plugin will increase the comparability and we encourage other researchers to do it. Table II presents the unresolved and fixed issues for nine Python projects, and compares the number of issues between default rules and extended rules for each project. B. What is the fixing prevalence of different issue types?(RQ2)
To quantify how much TD exists and investigate how prevalent the TD is in both all projects and each project, we use the 208 extended rules of SonarQube. A subset of 126 out of 208 rules are found in the nine selected Python projects.
To answer this RQ, we sum up all the issues, without differentiating among projects. The histogram of Figure 3 presents the distribution of the number of issues for each type: each vertical bar is an issue type, and its height is proportional to the number of issues of that type. The figure shows a strongly skewed distribution where some of issue types are introduced frequently but more than half of the issue types are introduced rarely.
The strongly skewed distribution of fixed issues types for is the same for both Python and Java.
We have seen that SonarQube has different issue types for Java projects and Python projects. Out of these 27 rules appear both in Python and Java. Even if the majority of the issues are different, the distribution of issue types that are being fixed is similar: a strongly skewed distribution with several issue types being introduced frequently and more than half of the issue types being introduced very rarely.
In the future work, we plan to explore in more detail the differences and similarities between Python and Java from the point of view of technical debt evolution. Especially we plan to investigate the types of issues that have been fixed during the evolution of Python projects and the amount of TD that is paid back.