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

Shaiful Chowdhury,Hisham Kidwai,Muhammad Asaduzzaman

2024-11-21

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.

Software Engineering

What problem does this paper attempt to address?

The core problem that this paper attempts to solve is: **Does Self - Admitted Technical Debt (SATD) really have a negative impact on software maintenance?**

Specifically, the authors note that although many studies have focused on the detection and removal of SATD and assumed that SATD is harmful to software maintenance, these assumptions lack substantial empirical evidence. Most previous studies have only explored the impact of SATD at the file or class level and have failed to provide clear evidence that SATD has a negative impact on software quality or maintenance. Therefore, this paper aims to fill this research gap through empirical analysis at the method level.

### Research Background

1. **Technical Debt**: It refers to the compromises made in technical quality in order to obtain short - term benefits, which may have an adverse impact on long - term software quality.
2. **Self - Admitted Technical Debt (SATD)**: It refers to the technical debt explicitly acknowledged by developers in the source code through comments, such as temporary solutions or areas for future improvement.
3. **Limitations of Existing Research**: Although many studies have explored the detection and removal of SATD, there are few studies on the actual impact of SATD on software maintenance, and the existing studies are mostly concentrated at the file or class level and have failed to provide sufficient evidence to support the negative impact of SATD.

### Research Motivation

1. **Simpler Maintenance Tasks at the Method Level**: Compared with the file or class level, maintenance tasks at the method level are easier to identify and solve and usually require less time.
2. **Effectiveness of Internal Metrics**: Many studies have shown that there is no obvious correlation between internal metrics at the file or class level and the maintenance burden, but at the method level, these metrics can be effective predictors of maintenance.
3. **Impact of Method Migration**: Since methods can be moved to different files through various transformations, tracking SATD at the file or class level may lead to inaccurate results.

### Research Questions

To solve the above problems, this paper proposes the following four research questions:

1. **RQ1: Do methods containing SATD affect code quality?**
- By evaluating 14 popular method - level code metrics, the results show that methods containing SATD usually have lower code quality, manifested as reduced readability, increased size and complexity.

2. **RQ2: Do methods containing SATD affect the change tendency of code?**
- The results show that methods containing SATD are more likely to change frequently, which indicates that SATD is a strong predictor of future maintenance challenges and leads to higher maintenance costs.

3. **RQ3: Do methods containing SATD affect the error - prone tendency of code?**
- The study finds that methods containing SATD are more likely to be associated with error - fixing commits, indicating that resolving SATD is crucial for improving maintainability and reliability.

4. **RQ4: How long does it take to resolve SATD?**
- The study finds that most SATD is never removed, and even if it is resolved, it often lasts a long time, and many SATD remain unresolved for more than one year.

### Main Contributions

- **Empirical Evidence**: Through the analysis of 774,051 Java methods, it provides empirical evidence of the negative impact of SATD on method - level code quality, change tendency and error - prone tendency.
- **Method - Level Analysis**: It emphasizes the importance of method - level analysis and reveals the limitations of previous studies at the file or class level.
- **Public Data Set**: In order to facilitate the reproduction and expansion of the study, the authors have made all the data sets used publicly available.

In conclusion, through empirical research at the method level, this paper verifies the negative impact of SATD on software maintainability and emphasizes the importance of early identification and management of SATD.