Characterizing and Mitigating Self-Admitted Technical Debt in Build Systems

TL;DR

This paper investigates self-admitted technical debt in build systems, analyzing comments in Maven projects to understand its causes, rationale, and resolution, and develops classifiers for automatic detection.

Contribution

It provides the first characterization of SATD in build systems, identifies common causes and rationales, and trains classifiers with promising accuracy for automatic detection.

Findings

Limitations in tools and libraries are the most frequent causes of SATD.

Developers often document SATD as issues to be fixed later.

Classifiers achieved an F1-score of 0.71-0.79 in detecting SATD reasons and purposes.

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.