An empirical study on self-admitted technical debt in modern code review

Kashiwa, Yutaro; Nishikawa, Rie; Kamei, Yasutaka; Kondo, Masanari; Shihab, Emad; Satô, Ryôsuke; Ubayashi, Naoyasu

doi:10.1016/j.infsof.2022.106855

Cited by 17 publications

(7 citation statements)

References 36 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The same suggestion is also proposed by the study on SATD between industry and open-source systems developers (Zampetti et al, 2021). Thus, researchers recently studied the presence of SATD in other software artifacts, i.e., build sys-tems (Xiao et al, 2022), issue reports (Xavier et al, 2020(Xavier et al, , 2022, and code reviews (Kashiwa et al, 2022). In our study, we use non-SATD as a baseline to better conclude the unique property of SATD clones.…”

Section: Related Workmentioning

confidence: 71%

Quantifying and characterizing clones of self-admitted technical debt in build systems

Xiao,

Zeng,

Wang

et al. 2024

Empir Software Eng

View full text Add to dashboard Cite

Self-Admitted Technical Debt (SATD) annotates development decisions that intentionally exchange long-term software artifact quality for short-term goals. Recent work explores the existence of SATD clones (duplicate or near duplicate SATD comments) in source code. Cloning of SATD in build systems (e.g., CMake and Maven) may propagate suboptimal design choices, threatening qualities of the build system that stakeholders rely upon (e.g., maintainability, reliability, repeatability). Hence, we conduct a large-scale study on 50,608 SATD comments extracted from Autotools, CMake, Maven, and Ant build systems to investigate the prevalence of SATD clones and to characterize their incidences. We observe that: (i) prior work suggests that 41-65% of SATD comments in source code are clones, but in our studied build system context, the rates range from 62% to 95%, suggesting that SATD clones are a more prevalent phenomenon in build systems than in source code; (ii) statements surrounding SATD clones are highly similar, with 76% of occurrences having similarity scores greater than 0.8; (iii) a quarter of SATD clones are introduced by the author of the original SATD statements; and (iv) among the most commonly

show abstract

Section: Related Workmentioning

confidence: 71%

Quantifying and characterizing clones of self-admitted technical debt in build systems

Xiao,

Zeng,

Wang

et al. 2024

Empir Software Eng

View full text Add to dashboard Cite

show abstract

“…To understand violation symptoms that developers face in practice, we selected four OSS projects from two communities, namely Open-Stack and Qt; these projects have been commonly used in previous studies (e.g., [26]) due to their long development history and rich textual artifacts. OpenStack 5 is a widely-used open source cloud software platform, on which many organizations (e.g., IBM and Cisco) collaboratively develop applications for cloud computing.…”

Section: Project Selectionmentioning

confidence: 99%

Warnings: Violation symptoms indicating architecture erosion

Liang

Avgeriou

2023

Information and Software Technology

View full text Add to dashboard Cite

“…The difference between our work and existing work is that we identified and analyzed PTD in the context of code review, which involves reliable human identification process (i.e., reviewers could consider taking full consideration of the contextual information and thus be better positioned to detect PTD in the code). Recently, an empirical study was conducted by Kashiwa et al to examine the relationship between SATD and code review process, which is the most related work to us [17]. However, in that work, the authors mined SATD only from the code comments that introduce SATD during the code review process.…”

Section: Related Work 21 Technical Debtmentioning

confidence: 99%

Potential Technical Debt and Its Resolution in Code Reviews: An Exploratory Study of the OpenStack and Qt Communities

Fu¹,

Peng²,

Rasheed³

et al. 2022

Preprint

View full text Add to dashboard Cite

Background: Technical Debt (TD) refers to the situation where developers make trade-offs to achieve short-term goals at the expense of long-term code quality, which can have a negative impact on the quality of software systems. In the context of code review, such sub-optimal implementations have chances to be timely resolved during the review process before the code is merged. Therefore, we could consider them as Potential Technical Debt (PTD) since PTD will evolve into TD when it is injected into software systems without being resolved. Aim: To date, little is known about the extent to which PTD is identified in code reviews. Many tools have been provided to detect TD, but these tools lack consensus and a large amount of PTD are undetectable by tools while code review could help verify the quality of code that has been committed by identifying issues, such as PTD. To this end, we conducted an exploratory study in an attempt to understand the nature of PTD in code reviews and track down the resolution of PTD after being identified. Method: We randomly collected 2,030 review comments from the Nova project of OpenStack and the Qt Base project of Qt. We then manually checked these review comments, and obtained 163 PTD-related review comments for further analysis. Results: Our results show that: (1) PTD can be identified in code reviews but is not prevalent. (2) Design, defect, documentation, requirement, test, and code PTD are identified in code reviews, in which code and documentation PTD are the dominant. (3) 81.0% of the PTD identified in code reviews has been resolved by developers, and 78.0% of the resolved TD was resolved by developers within a week. (4) Code refactoring is the main practice used by developers to resolve the PTD identified in code reviews. Conclusions: Our findings indicate that: (1) review-based detection of PTD is seen as one of the trustworthy mechanisms in development, and (2) there is still a significant proportion of PTD (19.0%) remaining unresolved when injected into the software systems. Practitioners and researchers should establish effective strategies to manage and resolve PTD in development.

show abstract

An empirical study on self-admitted technical debt in modern code review

Cited by 17 publications

References 36 publications

Quantifying and characterizing clones of self-admitted technical debt in build systems

Quantifying and characterizing clones of self-admitted technical debt in build systems

Warnings: Violation symptoms indicating architecture erosion

Potential Technical Debt and Its Resolution in Code Reviews: An Exploratory Study of the OpenStack and Qt Communities

Contact Info

Product

Resources

About