vix.ing · top · new · best · stats

Assessing technical debt by identifying design flaws in software systems

2012/08/07 by Radu Marinescu, R. Marinescu · 161 citations
Computer Science · Engineering · #Business #Code refactoring #Computer science #Debt #Eclipse #Engineering #Finance #Reliability engineering #Restructuring #Risk analysis (engineering) #Software #Software Engineering Research #Software Reliability and Analysis Research #Software System Performance and Reliability #Software development #Software engineering #Software system #Systems engineering #Technical debt

paper · doi:10.1147/jrd.2012.2204512

published in IBM Journal of Research and Development 56(5), 9:1-9:13 (IBM)

openalex publication_date 2012/08/07 · crossref created 2012/08/07 · crossref issued 2012/09/01 · crossref published 2012/09/01 · crossref published-print 2012/09/01 · openalex created_date 2025/10/10 · crossref deposited 2025/10/20 · crossref indexed 2026/08/03 · openalex updated_date 2026/08/03

Abstract

Tough time-to-market constraints and unanticipated integration or evolution issues lead to design tradeoffs that usually cause flaws in the structure of a software system. Thus, maintenance costs grow significantly. The impact of these design decisions, which provide short-term benefits at the expense of the system’s design integrity, is usually referred to as technical debt. In this paper, I propose a novel framework for assessing technical debt using a technique for detecting design flaws, i.e., specific violations of well-established design principles and rules. To make the framework comprehensive and balanced, it is built on top of a set of metrics-based detection rules for well-known design flaws that cover all of the major aspects of design such as coupling, complexity, and encapsulation. I demonstrate the effectiveness of the framework by assessing the evolution of technical debt symptoms over a total of 63 releases of two popular Eclipse® projects. The case study shows how the framework can detect debt symptoms and past refactoring actions. The experiment also reveals that in the absence of such a framework, restructuring actions are not always coherent and systematic, not even when performed by very experienced developers.

Cited by