Refactoring Debt: Myth or Reality? An Exploratory Study on the Relationship Between Technical Debt and Refactoring

TL;DR

This study investigates the relationship between technical debt and refactoring by analyzing open-source Java projects, revealing that developers often use refactoring to repay technical debt, which can inform tool development.

Contribution

It provides empirical evidence of the connection between technical debt repayment and refactoring activities in real-world software projects.

Findings

Refactoring is frequently used to remove self-admitted technical debt.

Developers refactor code to address specific technical debt issues.

Technical debt repayment often coincides with refactoring operations.

Abstract

To meet project timelines or budget constraints, developers intentionally deviate from writing optimal code to feasible code in what is known as incurring Technical Debt (TD). Furthermore, as part of planning their correction, developers document these deficiencies as comments in the code (i.e., self-admitted technical debt or SATD). As a means of improving source code quality, developers often apply a series of refactoring operations to their codebase. In this study, we explore developers repaying this debt through refactoring operations by examining occurrences of SATD removal in the code of 76 open-source Java systems. Our findings show that TD payment usually occurs with refactoring activities and developers refactor their code to remove TD for specific reasons. We envision our findings supporting vendors in providing tools to better support developers in the automatic repayment of technical debt.