Abstract

While technical debt grows in absolute numbers as software systems evolve over time, the density of technical debt (technical debt divided by lines of code) is reduced in some cases. This can be explained by either the application of refactorings or the development of new artifacts with limited Technical Debt. In this paper we explore the second explanation, by investigating the relation between the amount of Technical Debt in new code and the evolution of Technical Debt in the system. To this end, we compare the Technical Debt Density of new code with existing code, and we investigate which of the three major types of code changes (additions, deletions and modifications) is primarily responsible for changes in the evolution of Technical Debt density. Furthermore, we study whether there is a relation between code quality practices and the ‘cleanness’ of new code. To obtain the required data, we have performed a large-scale case study on twenty-seven open-source software projects by the Apache Software Foundation, analyzing 66,661 classes and 56,890 commits. The results suggest that writing “clean” (or at least “cleaner”) new code can be an efficient strategy for reducing Technical Debt Density, and thus preventing software decay over time. The findings also suggest that projects adopting an explicit policy for quality improvement, e.g., through discussions on code quality in board meetings, are associated with a higher frequency of cleaner new code commits. Therefore, we champion the establishment of processes that monitor the density of Technical Debt of new code to control the accumulation of Technical Debt in a software system.

Highlights

  • T ECHNICAL DEBT is a metaphor that captures in monetary terms, the cost of additional maintenance effort caused by technical shortcuts taken usually for expediency [1]

  • The results indicate that: (a) in the majority of the cases the code smells are introduced into the projects with the creation of the corresponding classes or files, (b) while projects evolve over time, “smelly” code artifacts tend to become more problematic, (c) new code smells are introduced when software engineers implement new features or when they extend the functionality of the existing ones, (d) the developers who introduce new code smells into the projects, are the ones who work under pressure and not necessarily the newcomers, and (e) the majority of the smells are not removed during the project’s evolution and few of them are removed as a direct consequence of refactoring operations

  • The Technical Debt metaphor is usually associated with degrading quality trends in software systems

Read more

Summary

Introduction

T ECHNICAL DEBT is a metaphor that captures in monetary terms, the cost of additional maintenance effort caused by technical shortcuts taken usually for expediency [1]. The density of technical debt, i.e., the normalized amount of Technical Debt per line of code, remains in some cases stable, or is even reduced over time; we have observed this in our previous work on the evolution of the Apache ecosystem [2]. This raises the question how such systems manage to maintain or improve their Technical Debt density. The first is that these systems follow a process of systematic perfective maintenance, mostly through the application of refactorings [4]. Refactoring activities are rarely applied systematically in Manuscript received April 19, 2005; revised August 26, 2015

Objectives
Results
Discussion
Conclusion
Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call