Understanding automated and human-based technical debt identification approaches-a two-phase study

Rodrigo O Spínola,Nico Zazworka,Forrest Shull,Antonio Vetro,Carolyn Seaman

doi:10.1186/s13173-019-0087-5

Abstract

ContextThe technical debt (TD) concept inspires the development of useful methods and tools that support TD identification and management. However, there is a lack of evidence on how different TD identification tools could be complementary and, also, how human-based identification compares with them.ObjectiveTo understand how to effectively elicit TD from humans, to investigate several types of tools for TD identification, and to understand the developers’ point of view about TD indicators and items reported by tools.MethodWe asked developers to identify TD items from a real software project. We also collected the output of three tools to automatically identify TD and compared the results in terms of their locations in the source code. Then, we collected developers’ opinions on the identification process through a focus group.ResultsAggregation seems to be an appropriate way to combine TD reported by developers. The tools used cannot help in identifying many important TD types, so involving humans is necessary. Developers reported that the tools would help them to identify TD faster or more accurately and that project priorities and current development activities are important to be considered together, along with the values of principal and interest, when deciding to pay off a debt.ConclusionThis work contributes to the TD landscape, which depicts an understanding between different TD types and how they are best discovered.

Highlights

The technical debt (TD) concept brings a new perspective on how software development tasks are discussed and managed
We examine the top 10% of the sorted list and determined how many source files in that 10% corresponded to TD items reported by developers
An “s” on the front face of a box shows that the TD item was located in the source code by the subject who reported it

Summary

Introduction

The technical debt (TD) concept brings a new perspective on how software development tasks are discussed and managed. It describes the tradeoff between the short-term payoffs (such as a timely software release) of delaying some technical development activities and the long-term consequences of those delays [7]. TD presents an actual or contingent liability whose impact is limited to It is common for a software project to incur TD during the development process since small amounts of debt can increase productivity [43]. According to Guo et al [15], the management of TD can center on a TD list This list contains TD items (in the following referred to as items) that represent tasks that were left undone, but that run a risk of causing future problems if not completed. If a debt item is a set of classes that need to be refactored, the historical cost of modification of those classes can be used as the future modification cost (principal of the debt item) estimation

Results

Discussion

Conclusion