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

Abstract

Context: The 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. Objective: To 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. Method: We 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. Results: Aggregation 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.Conclusion: This work contributes to the TD landscape, which depicts an understanding between different TD types and how they are best discovered.

The Gap between the Admitted and the Measured Technical Debt: An Empirical Study

“…Please note that we prepared a short workshop for the developers in order to present the technical debt metaphor and demonstrated the self-assessment process. We rely on the research findings, which state a connection between the identified technical debt items and the ownership of the source code [25]. The developers were asked to report the title, description, technical debt type and sub-type (closed selection), and assessed effort to mediate for every technical debt item.…”

A survey on software test automation return on investment, in organizations predominantly from Bengaluru, India

“…Similarly, there is research for identifying tech debt in test automation and applying software design principles for test automation development. [75][76][77] The criteria for when and what to automate are decided by the factors eligibility, priority, cost, coverage, end user usage, quality, maintainability, and time. [78][79][80] Certainly, there are various impediments for automation, and the factors contributing to hindrance of a robust test automation suite are discussed in Reference 81.…”

Assessing IDEA Diagrams for Supporting Analysis of Capabilities and Issues in Technical Debt Management

“…Technical debt (TD) emerges from intentional shortcuts or even mistakes taken by software practitioners in their projects [1,2]. Incurring debt can bring short-term benefits, 2 usually in terms of high productivity, but also long-term drawbacks, making the software difficult to evolve [3,4,5]. By performing TD management activities, a software team can make TD items visible and under control, allowing it to balance benefits and drawbacks of debt presence [6].…”