Hidden in Plain Sight: Where Developers Confess Self-Admitted Technical Debt

TL;DR

This study addresses where developers admit technical debt by linking Self-Admitted Technical Debt (SATD) comments to surrounding code within the PENTACET Java dataset. It introduces normalization metrics to quantify SATD density by location, preceding/succeeding statements, and within-SATD patterns, and analyzes 225k SATD instances across 9k repositories. Findings show SATD is predominantly non-header and concentrates around inline constructs such as definitions, conditionals, branching, and exception handling, with recurring patterns that precede or follow new functionality or refactoring. The work provides actionable insights for context-aware SATD detection and management, suggesting that debt indicators are tied to implementation-level trade-offs rather than purely design-level issues. Overall, the paper advances a spatial, context-rich understanding of SATD, enabling more precise tooling and cross-language generalization in future research.

Abstract

Context. Detecting Self-Admitted Technical Debt (SATD) is crucial for proactive software maintenance. Previous research has primarily targeted detecting and prioritizing SATD, with little focus on the source code afflicted with SATD. Our goal in this work is to connect the SATD comments with source code constructs that surround them. Method. We leverage the extensive SATD dataset PENTACET, containing code comments from over 9000 Java Open Source Software (OSS) repositories. We quantitatively infer where SATD most commonly occurs and which code constructs/statements it most frequently affects. Results and Conclusions. Our large-scale study links over 225,000 SATD comments to their surrounding code, showing that SATD mainly arises in inline code near definitions, conditionals, and exception handling, where developers face uncertainty and trade-offs, revealing it as an intentional signal of awareness during change rather than mere neglect.