Characterizing and Mitigating Self-Admitted Technical Debt in Build Systems

Abstract

Technical Debt is a metaphor used to describe the situation in which long-term software artifact quality is traded for short-term goals in software projects. In recent years, the concept of self-admitted technical debt (SATD) was proposed, which focuses on debt that is intentionally introduced and described by developers. Although prior work has made important observations about admitted technical debt in source code, little is known about SATD in build systems. In this paper, we set out to better understand the characteristics of SATD in build systems. To do so, through a qualitative analysis of 500 SATD comments in the Maven build system of 291 projects, we characterize SATD by location and rationale (reason and purpose). Our results show that limitations in tools and libraries, and complexities of dependency management are the most frequent causes, accounting for 50% and 24% of the comments. We also find that developers often document SATD as issues to be fixed later. As a first step towards the automatic detection of SATD rationale, we train classifiers to detect the two most frequently occurring reasons and the four most frequently occurring purposes of SATD in the content of comments in Maven build systems. The classifier performance is promising, achieving an F1-score of 0.71-0.79. Finally, within 16 identified 'ready-to-be-addressed' SATD instances, the three SATD submitted by pull requests and the five SATD submitted by issue reports were resolved after developers were made aware. Our work presents the first step towards understanding technical debt in build systems and opens up avenues for future work, such as tool support to track and manage SATD backlogs.

Quantifying and characterizing clones of self-admitted technical debt in build systems

“…Finally, we retrieve 2,628,919 comments from build specification files in total. Similar to our prior work (Xiao et al, 2022), we identify SATD comments using the keywords-based approach of Potdar and Shihab (2014). We further discuss the rationale of electing the keywords-based approach instead of the existing machine learning based approach in Section 5.2.…”

“…Moreover, to reduce the impact of noisy text in comments, we remove special characters by using the regular expression [^A-Za-z0-9]+. Since stop words (e.g., "for" and "until") could convey critical semantics in the context of SATD comments, we opt to exclude stop word removal (Maipradit et al, 2020b;Xiao et al, 2022). We further filter out uninformative SATD comments that contain a single word (e.g., "TODO") since these annotations are highly likely to be cloned in the software development process.…”

Understanding the Role of Images on Stack Overflow

“…To understand the characteristics of images on Stack Overflow, we conducted a qualitative study of a statistically representative sample of all developer questions that contain at least one image in our dataset. Since images may come from different sources and contain different types of content, we adopt three dimensions of (a) the image source, (b) the image content, and (c) the purpose served by the image, which is similar to prior work [15,16]. Furthermore, to inform the tool design on whether support for images is crucial, we analyze the relationship between the image and the comprehension of the question understanding.…”

More than React: Investigating The Role of Emoji Reaction in GitHub Pull Requests

“…To discover as complete of a list of reasons as possible, we strive for theoretical saturation (Eisenhardt, 1989) to achieve analytical generalization. Similar to the prior work (Xiao et al, 2021), we initially set our saturation criterion to 50. Then the first two authors continue to code randomly selected inconsistent comments until no new codes have been discovered for 50 consecutive comments.…”

“…Instead, we divided all PRs that contain emoji reactions into the ones by first-time contributors and the other ones by non first-time contributors. Third, during the manual classification of reasons behind sentiment inconsistency (RQ3), we did not calculate the Kappa score as the open coding process does not require it (Hirao et al, 2019;Xiao et al, 2021). 3.…”