Management of Self-Admitted Technical Debt using Machine Learning

Abstract

Technical debt is a prevalent phenomenon in software development, where developers make sub-optimal decisions to achieve short-term goals, often at the expense of long-term evolvability and maintainability. These decisions, analogous to financial debt, incur principal and interest over time, which can negatively affect various aspects of software development, and especially making changes either for implementing new features or for fixing bugs. Therefore, effective management of technical debt is crucial to ensure software health in the long run.One way to manage technical debt is by identifying and documenting it explicitly within various software artifacts. This category of technical debt is known as Self-Admitted Technical Debt (SATD), where developers use textual artifacts, such as source code comments, commit messages, issue tracking systems, and pull requests, to indicate the presence of technical debt and its possible consequences. For example, a developer may write a code comment like "TODO: this method needs refactoring" to admit that the current code is not optimal and requires improvement in the future. By identifying and analyzing SATD, developers can gain insights into the technical debt landscape of a software system and take appropriate actions to address it.Despite the prevalence and importance of technical debt in software development, current research and practice on managing technical debt, especially SATD, are inadequate. Existing approaches mainly focus on identifying SATD from source code comments, neglecting other textual artifacts that contain valuable information about SATD, such as issues, commit messages, and pull requests. This oversight leads to undetected SATD accumulation, which can potentially spiral out of control and threaten software quality and sustainability. Moreover, code comments often lack essential contextual and repayment information that can help developers understand the rationale, implications, and solutions for SATD. This lack of visibility hinders informed decisions to repay SATD and hides the true status of resolved SATD. Therefore, there is a need for novel and comprehensive approaches to identify, analyze, and repay SATD from various textual artifacts in software projects.To fulfill this objective, as a first step we explore SATD in issue tracking systems before considering multiple sources. By examining SATD in these systems, we can Abstract better comprehend the nature, causes, and repayment of SATD in software projects. To this end, we conducted a qualitative analysis on a sample of 500 issues, identifying and analyzing sentences in issues that refer to SATD. Our research revealed eight types of SATD found in issue trackers: architecture, build, code, defect, design, documentation, requirement, and test debt. We also identified three distinct cases of technical debt identification in issue trackers, with only a small fraction (13.1%) of technical debt being recognized by its creators. Interestingly, the majority of SATD was repaid primarily by those who identi...