A systematic literature review of technical debt prioritization

Kumar

J Software Evolu Process

2023

Code smells indicate poor design and imperfection in coding style. They increase maintenance costs and degrade software quality. Detecting and mitigating these code smells reduce the effects of flaws present in the software design. However, to save time and effort, it is a good practice to prioritize critical code smells and resolve them first. There have been various empirical studies on code smell prioritization in the last decades. Although the research community has been continuously working on the prioritization of code smells, yet a systematic mapping of all these studies would provide a panorama of research work. With this motivation, we selected 39 primary studies published between May 2011 and May 2022 and classified them based on seven factors: (i) code smells, (ii) factors, (iii) evaluation techniques, (iv) tools, (v) ranking formulas, (vi) data sets used, and (vii) measurements used for validating the research work. This paper aims to outline and discuss the prioritization procedure for code smells in object‐oriented software systems. The issues and recommendations for every question act as input for the researchers and industrialists for further research. Some issues for further investigation are less coverage of architecture smells, limited ranking formulas, lack of automated evaluation techniques, and so forth.

Section: Related Researchmentioning

confidence: 99%

Code smell prioritization in object‐oriented software systems: A systematic literature review

Kumar

J Software Evolu Process

2023

“…Several researchers have investigated self-admitted technical debt in source code for various purposes including its identification [13,14,44,16,26,53,54,1], removal [57,28], prioritization [3,2,20], recommendation when to admit SATDs [55], or the analysis of its impact on source code quality [51] -to mention a few examples.…”

Section: Related Workmentioning

confidence: 99%

“…Alves et al [3] conducted a systematic literature review identifying 29 technical debt prioritization approaches. Among the 29 approaches, 70.83% address a specific type of technical debt, while the remaining approaches can be applied to any kind of technical debt.…”

Section: Surveys and Literature Reviews On Technical Debtmentioning

confidence: 99%

“…This phenomenon led to the concept of technical debt, i.e., implementation trade-offs made by developers during rushed development tasks. Since Cunningham first described technical debt almost 30 years ago [11], many researchers have studied its impact on software development [3,4,23,38]. In general, researchers agree that it leads to low quality (in particular maintainability), and makes further changes more expensive in the long run [24,51].…”

Section: Introductionmentioning

confidence: 99%

“…While these studies recognize the importance of technical debt in data-intensive systems, the problem has not received much attention. Although several researchers have investigated the detection, persistence and impact of technical debt in traditional software systems (e.g., [23,4,38,3,26,24,51]), data-intensive systems remained out of focus. In particular, we still do not know much about the prevalence and persistence of technical debt in data-intensive systems.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

FIXME: Synchronize with Database An Empirical Study of Data Access Self-Admitted Technical Debt

Muse¹,

Nagy²,

Cleve³

et al. 2022

Preprint

Developers sometimes choose design and implementation shortcuts due to the pressure from tight release schedules. However, shortcuts introduce technical debt that increases as the software evolves. The debt needs to be repaid as fast as possible to minimize its impact on software development and software quality. Sometimes, technical debt is admitted by developers in comments and commit messages. Such debt is known as self-admitted technical debt (SATD). In data-intensive systems, where data manipulation is a critical functionality, the presence of SATD in the data access logic could seriously harm performance and maintainability. Understanding the composition and distribution of the SATDs across software systems and their evolution could provide insights into managing technical debt efficiently. We present a large-scale empirical study on the prevalence, composition, and evolution of SATD in data-intensive systems. We analyzed 83 open-source systems relying on relational databases as well as 19 systems relying on NoSQL databases. We detected SATD in source code comments obtained from different snapshots of the subject systems. To understand the evolution dynamics of SATDs, we conducted a survival analysis. Next, we performed a manual analysis of 361 sample data-access SATDs, investigating the composition of data-access SATDs and the reasons behind their introduction and removal. We identified 15 new SATD categories, out of which 11 are specific to database access operations. We found that most of the data-access SATDs are introduced in the later stages of change history rather than at the beginning. We also observed that bug fixing and refactoring are the main reasons behind the introduction of data-access SATDs.

J Software Evolu Process

The Pandora's box of social, process, and people debts in software engineering

Ahmad

Gustavsson

2022

In software engineering, technical debt (TD) has been widely investigated, but debt regarding social issues, people, and processes has not been explored as much. It should be noted here that we use nontechnical debt (NTD) as an umbrella term to cover social, process, and people debts. Although the number of studies on NTD in software is increasing, the majority of them are descriptive rather than rigorous, and there is no systematic development of cumulative knowledge. As a result, identifying the fundamental causes of NTD and the associated mitigation techniques in software engineering is challenging. Therefore, this study investigates the scientific evidence regarding NTD till date by conducting a systematic mapping review of software engineering research between January 2000 and October 2021. The search strategy resulted in 175 studies, 17 of which were identified as unique and relevant primary papers. The primary studies show that NTD and TD are inextricably linked. In addition, this study also captured a plethora of causes and mitigation strategies for managing NTD and thus makes four important contributions: (i) highlighting state‐of‐the‐art NTD research; (ii) identification of the reported causes and mitigation strategies in the primary papers; and (iii) determination of opportunities for future NTD research.