Evidence is All We Need: Do Self-Admitted Technical Debts Impact Method-Level Maintenance?

TL;DR

Self-Admitted Technical Debt (SATD) is widely discussed as a maintenance risk, but prior evidence was inconclusive and often at file/class level. This study conducts a method-level empirical analysis over 774,051 Java methods from 49 open-source projects, addressing code quality, change-proneness, bug-proneness, and SATD removal time. The results show SATD methods are larger, more complex, less readable, more change- and bug-prone, and that many SATDs remain unresolved for long periods, underscoring long-term maintenance costs. The authors provide a public dataset and discuss practical and research implications for early SATD detection and remediation.

Abstract

Self-Admitted Technical Debt (SATD) refers to the phenomenon where developers explicitly acknowledge technical debt through comments in the source code. While considerable research has focused on detecting and addressing SATD, its true impact on software maintenance remains underexplored. The few studies that have examined this critical aspect have not provided concrete evidence linking SATD to negative effects on software maintenance. These studies, however, focused only on file- or class-level code granularity. This paper aims to empirically investigate the influence of SATD on various facets of software maintenance at the method level. We assess SATD's effects on code quality, bug susceptibility, change frequency, and the time practitioners typically take to resolve SATD. By analyzing a dataset of 774,051 methods from 49 open-source projects, we discovered that methods containing SATD are not only larger and more complex but also exhibit lower readability and a higher tendency for bugs and changes. We also found that SATD often remains unresolved for extended periods, adversely affecting code quality and maintainability. Our results provide empirical evidence highlighting the necessity of early identification, resource allocation, and proactive management of SATD to mitigate its long-term impacts on software quality and maintenance costs.

Figures (4)

• Figure 1: Differences in distribution for Size, McCabe, totalFanOut, Readability, SimpleReadability, and MaintainabilityIndex in the aggregated data. Clearly, SATD methods tend to have larger sizes, more complexity, more dependency, and lower readability, and worse Maintainability Index compared to NOT-SATD methods.
• Figure 2: Differences in distribution for #Revisions, DiffSizes, and CriticalEditDistances. Clearly, SATD methods tend to have more revisions and larger change sizes. The results are very similar for NewAdditions and EditDistances, therefore, not presented.
• Figure 3: Differences in the distribution of bug ratios in three datasets: SATD methods tend to have more bugs than NOT-SATD methods in all datasets.
• Figure 4: Figures (a) and (b) show the distribution of the percent of unresolved SATD methods and the distribution of SATD removal time in aggregated data, respectively. Figures (c) and (d) show the distribution of the means and medians of SATD removal time for all 49 projects.