The Technical Debt Density Over Multiple Releases and the Refactoring Story

Abstract

Do developers postpone fixing Technical Debt (TD) in software systems? TD is a metaphor that refers to short-term decisions in software development that may affect the cost of the software development life cycle. The bad smell is an imperfect solution in the software system that negatively impacts the internal software quality and maintainability. In this paper, we will study five open-source software projects (OSSPs) that have several releases and also estimate the numbers of architecture smells (ASs), design smells (DSs), and code smells (CSs) for every release. Designite will be used to detect smells. We describe a case study conducted to explore the following: (1) What is the average smells density for architecture, design, and code smells in an OSSP? (2) Does the density of each smell type increase over multiple releases? (3) What percentage of each smell-type density is eliminated by refactoring? We collected around 2 million LOC from five OSSPs that have multiple releases from the GitHub repository to statistically analyze the software concerning the smells as indicators of TD. We find 36% of Architecture Technical Debt (ATD) is Cyclic Dependency, while 33% of Design Debt (DD) is Cyclically-dependent Modularization. More than 70% of Code Debt (CD) is Magic Number. Even though the developers do refactoring between releases, the TD density in general increases. On average, by refactoring, developers remove around 48%, 16%, and 22% from the introduced ATD, DD, and CD from their next release, respectively.