Technical Debt Items Research Articles

Investigating the Point of View of Project Management Practitioners on Technical Debt - A Study on Stack Exchange

Context: Technical debt (TD) can bring short-term benefits to software projects, but its presence is associated with issues such as decreasing product quality. Recent literature has proposed various approaches for identifying and managing TD, but most of them focus on the software developers’ point of view. Little is known about how project management practitioners perceive and manage TD items. Goal: This work aims to investigate how project management practitioners discuss and experience TD. Method: To achieve this goal, our work mines, curates, and selects a total of 108 TD-related discussions on the Stack Exchange Project Management (SEPM) Q&A site. These discussions amount to 547 posts and 882 text comments on the subject. We analyze this data set quantitatively and qualitatively, using open coding to derive TD types, indicators, and management practices. Results: We identified 74 indicators used for recognizing debt items and 126 TD management practices. The types of debt most discussed at SEPM are process and people debts. This contradicts studies done with developers where code and design debts are most discussed. Conclusion: The perspective considered by project management practitioners to analyze the TD phenomenon is different from the one considered by other roles in the software development process. Our work organizes the identified TD indicators and management practices into a Sankey diagram, which may assist TD management practitioners and serve as guidance for future research on the subject.

LEAP – A Process for Identifying Potential Technical Debt in Iterative System Development

AbstractSystems engineering has seen a rise in the use of iterative methods to design and develop both hardware and software systems which allow for system refinement to be responsive to user needs. However, focusing on items with high value to the user can result in technical debt, where technical compromises made for short‐term gain impact the long‐term health of the system. Current methods for identifying technical debt focus on finding existing technical debt items within a system and not on proactive identification of technical debt during the iterative system planning process. This paper presents a novel technique to identify technologies that impact the ability of the system to satisfy the needs of its stakeholders. The method is used to evaluate different choices of technological implementations in both the temporal and the functional dimensions to reduce the risk of incurring technical debt which prevents the successful delivery of the system.

Technical debt in the engineering of complex systems

AbstractThe metaphor of technical debt (TD) is widely adopted in the software engineering field, referring to short‐term compromises in software artifacts in exchange for speed or to meet release schedules or other constraints. The implication is that TDs accumulate over time, and may eventually make rework or maintenance very expensive or even impossible. The analogy is generally applicable in the systems engineering field, particularly concerning numerous program cancellation and obsolescence challenges due to premature decisions made in early acquisition phases. This paper adapts this metaphor of TD to the systems engineering field, and proposes a TD taxonomy to support the early identification and assessment of TD items in engineering complex systems, especially in the early life cycle phases of engineering complex, distributed systems. The taxonomy identifies seven TD types: functionality, performance, interoperability, version conflicts, documentation and support, system evolution, and organic, based on systematic indicators and signs discoverable during early acquisition activities. We expect that the notion and the taxonomy of TD will offer an additional perspective for design decisions that will help mitigate challenging integration and obsolescence issues in the engineering of complex systems.

Technical Debt Prioritization in Telecommunication Applications: Why the Actual Refactoring Deviates from the Plan and How to Remediate It? Case Study in the COVID Era

This paper focuses on application of a technical debt prioritisation technique in telecommunication software managing a fleet of devices for a video surveillance system. Technical debt for this application was gathered, categorised and prioritised according to the Continuous Debt Valuation Approach (CoDVA), previously proposed by the authors. The following research question was posed: Is prioritising technical debt reduction based on CoDVA effective (i.e., executed as per plan, bringing tangible benefits)? The outbreak of COVID-19 pandemic caused unprecedented disturbance to the engineering organisations worldwide, therefore the technical debt identification phase had to be adapted to cope with a switch to forced working-from-home mode. This was achieved by applying the Wisdom of Crowds method, ensuring broad participation of engineers, and providing a fairly complete picture of the accrued technical debt. Nevertheless, the actual technical debt reduction activities did not follow exactly the expected guidelines. The three main causes of this phenomenon were discovered: continuous refactoring approach, sizing of technical debt items, and the broadened scope of refactoring activities. Therefore, as a result of this case study we propose to adopt a specific broadened definition of technical debt and follow a few rules for defining its scope and granularity.

Software practitioners’ point of view on technical debt payment

Context:Technical debt (TD) payment refers to the activity of expending maintenance effort and resources to make up for the effects of previous technical compromises. Aims:To investigate if software practitioners have paid debt items off in their projects, the practices that have been used for paying off debt items, and the issues that hamper the implementation of these practices. Method:We analyze 653 responses collected by surveying practitioners from six countries about TD payment. Results:Practitioners have not paid off TD items in most cases. We identified 27 reasons for not paying off those items and 32 payment-related practices. Practices are mainly related to internal quality issues, while reasons for not paying TD off are mostly associated with planning and management issues. Lastly, we identified relationships between practices and between reasons, indicating that both can appear in combination. Conclusion:. We use different views to consolidate the set of information on TD payment, extending the conceptual model for TD and organizing the set of practices and reasons into a TD payment map. We believe that the model and the map can support practitioners in planning their TD payment strategy.

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

Technical debt is a well understood and used concept in IT development. The metaphor, rooted in the financial world, captures the amount of work that development teams owe to a product. Every time developers take a shortcut within development, the technical debt accumulates. Technical debt identification can be accomplished via manual reporting on the technical debt items, which is called self-admitted technical debt. Several specialised methods and tools have also emerged that promise to measure the technical debt. Based on experience in the community, the impression emerged that the measured technical debt is of a significantly different amount than the self-admitted debt. In this context, we decided to perform empirical research on the possible gap between the two. We investigated 14 production-grade software products while determining the amount of accumulated technical debt via (a) a self-admitting procedure and (b) measuring the debt. The outcomes show clearly the significant difference in the technical debt reported by the two methods. We urge development and quality-assurance teams not to rely on technical debt measurement alone. The tools demonstrated their strength in identifying low-level code technical debt items that violate a set of predefined rules. However, developers should have additional insight into violations, based on the interconnected source code and its relation to the domain and higher-level design decisions.

Further investigation of the survivability of code technical debt items

AbstractContext: Technical debt (TD) discusses the negative impact of sub‐optimal decisions to cope with the need‐for‐speed in software development. Code technical debt items (TDI) are atomic elements of TD that can be observed in code artifacts. Empirical results on open‐source systems demonstrated how code‐smells, which are just one type of TDIs, are introduced and “survive” during release cycles. However, little is known about whether the results on the survivability of code‐smells hold for other types of code TDIs (i.e., bugs and vulnerabilities) and in industrial settings. Goal: Understanding the survivability of code TDIs by conducting an empirical study analyzing two industrial cases and 31 open‐source systems from Apache Foundation. Method: We analyzed 133,670 code TDIs (35,703 from the industrial systems) detected by SonarQube (in 193,196 commits) to assess their survivability using survivability models. Results: In general, code TDIs tend to remain and linger for long periods in open‐source systems, whereas they are removed faster in industrial systems. Code TDIs that survive over a certain threshold tend to remain much longer, which confirms previous results. Our results also suggest that bugs tend to be removed faster, while code smells and vulnerabilities tend to survive longer.

The Risk of Generating Technical Debt Interest: A Case Study

Technical Debt (TD) interest refers to the extra maintenance costs incurred by the very existence of TD items in a system. The generation of TD interest can make or break a system: too little interest and the effect of TD is negligible; too much interest and the system becomes unsustainable. In this paper, we consider the generation of interest as a risk and present a metric to quantify this risk. Subsequently, we validate this metric in two ways. First, we explore whether the metric can be effectively used to prioritize TD remediation. Second, we investigate if adding new code reduces the risk of interest generation. The results of the study suggest that: (a) the proposed risk management metric is capable of efficiently prioritizing TD items; and (b) that the new code that is introduced in the system is usually less risky for producing interest, compared to legacy code.

On the diffuseness of technical debt items and accuracy of remediation time when using SonarQube

Context. Among the static analysis tools available, SonarQube is one of the most used. SonarQube detects Technical Debt (TD) items—i.e., violations of coding rules—and then estimates TD as the time needed to remedy TD items. However, practitioners are still skeptical about the accuracy of remediation time estimated by the tool. Objective. In this paper, we analyze both diffuseness of TD items and accuracy of remediation time, estimated by SonarQube, to fix TD items on a set of 21 open-source Java projects. Method. We designed and conducted a case study where we asked 81 junior developers to fix TD items and reduce the TD of 21 projects. Results. We observed that TD items are diffused in the analyzed projects and most items are code smells. Moreover, the results point out that the remediation time estimated by SonarQube is inaccurate and, as compared to the actual time spent to fix TD items, is in most cases overestimated. Conclusions. The results of our study are promising for practitioners and researchers. The former can make more aware decisions during project execution and resource management, the latter can use this study as a starting point for improving TD estimation models.

Identifying self-admitted technical debt through code comment analysis with a contextualized vocabulary

Abstract Context Previous work has shown that one can explore code comments to detect Self-Admitted Technical Debt (SATD) using a contextualized vocabulary. However, current detection strategies still return a large number of false positives items. Moreover, those strategies do not allow the automatic identification of the type of debt of the identified items. Objective This work applies, evaluates, and improves a set of contextualized patterns we built to detect self-admitted technical debt using code comment analysis. We refer to this set of patterns as the self-admitted technical debt identification vocabulary. Method We carry out three empirical studies. Firstly, 23 participants analyze the patterns of a previously defined contextualized vocabulary and register their level of importance in identifying SATD items. Secondly, we perform a qualitative analysis to investigate the relation between each pattern and types of debt. Finally, we perform a feasibility study using a new vocabulary, improved based on the results of the previous empirical studies, to automatically identify self-admitted technical debt items, and types of debt, that exist in three open source projects. Results More than half of the new patterns were considered decisive or very decisive to detect technical debt items. The new vocabulary was able to find items associated to code, design, defect, documentation, and requirement debt. Thus, the result of the work is an improved vocabulary that considers the level of importance of each pattern and the relationship between patterns and debt types to support the identification and classification of SATD items. Conclusion The studies allowed us to improve a vocabulary to identify self-admitted technical debt items through code comments analysis. The results show that the use of pattern-based code comment analysis can contribute to improve existing methods, or create new ones, for automatically identifying and classifying technical debt items.

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

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.

VisminerTD: a tool for automatic identification and interactive monitoring of the evolution of technical debt items

Technical debt (TD) contextualizes problems faced during software evolution considering the tasks that are not carried out adequately during software development. Software TD is a type of debt that brings a short-term benefit, but which may have to be paid with interest later on in the software development life cycle. Its presence brings risks to the project and can reduce its quality. It is worthwhile to have automatic mechanisms to monitor it, as TD monitoring requires the analysis of large amounts of complex data. Therefore, the combination of software metrics and code comment analysis, in the identification, and information visualization techniques, in monitoring, present themselves as a promising strategy to manage TD. This work presents VisminerTD, a tool that allows the automatic identification and interactive monitoring of the evolution of TD items by combining software metrics, code comment analysis, and information visualization. To evaluate its applicability, a feasibility study was carried out considering JUnit 4 and Apache Ant software projects. The results indicated that VisminerTD can support software development teams in monitoring TD items. In addition, a second case study was performed to assess the feasibility of the proposed tool regarding its usefulness, ease of use, and self-predicted future use. The results provided positive evidence on the use of the proposed tool, indicating (i) that it can be useful in supporting TD Identification and TD monitoring activities and (ii) that it can bring gains in terms of comprehensiveness and efficacy when evaluating the desirable time to identify and monitor different types of debt. Given the current scenario characterized by limited options of tools that combine different information to support automatic identification and monitoring of the evolution of TD items in software projects, VisminerTD can approximate the state-of-the-art and the state-of-the-practice in the TD area, contributing to a wider dissemination of the concept.

Cross-disciplinary and cross-life-cycle-phase Technical Debt in automated Production Systems: two industrial case studies and a survey

Technical Debt (TD) metaphor was introduced at classical software engineering domain more than two decades ago. Outcomes of TD research have been gradually showing the benefits, which support practitioners to identify and remove TD items, thus reduce the maintenance cost. Recently, TD concept has just been successfully introduced into automated Production Systems (aPS) domain. aPS have long operation time, which has significant maintenance cost. In aPS domain, the research about TD is more complex, because besides software, aPS consist of other disciplines such as mechanical and electrical parts. Strong relationships of these three disciplines have substantial influences to development and maintenance phases of aPS. Thus, it is a challenge to study TD items in this domain. We need a broader investigation with involvements from multiple departments, to examine TD in aPS, rather than just analyze software part. However, up to now, most researches about TD in this domain still focus on software part only. This research studies TD items in aPS concerning the surround factors and impacts of these factors to the software side. The research method is TD4aPS, an adaption of SWMAT4aPS benchmark process to TD research for aPS. We select and present two typical case studies in the paper. One case is from a machine manufacturer. Another case is from a plant manufacturer. Two typical characteristics of TD in aPS domain are shown: cross-disciplinary and cross-life-cycle-phase. From analysis, the detected TD items are classified then short- and long-term recommendations are proposed. We validated qualitative results in case studies by quantitative results from an online survey received from German industrial companies working with aPS at 40 different markets.

On the interest of architectural technical debt: Uncovering the contagious debt phenomenon

AbstractA known problem in large software companies is to balance the prioritization of short‐term and long‐term business goals. As an example, architecture suboptimality (Architectural Technical Debt), incurred to deliver fast, might hinder future feature development. However, some technical debt generates more interest to be paid than other. We conducted a multi‐phase, multiple‐case embedded case study comprehending 9 sites at 6 large international software companies. We have investigated which architectural technical debt items generate more interest , how the interest occurs during software development and which costly extra‐activities are triggered as a result. We presented a taxonomy of the most dangerous items identified during the qualitative investigation and a model of their effects that can be used for prioritization, for further investigation and as a quality model for extracting more precise and context‐specific metrics. We found that some architectural technical debt items are contagious, causing the interest to be not only fixed, but potentially compound, which leads to the hidden growth of interest (possibly exponential). We found important factors to be monitored to refactor the debt before it becomes too costly. Instances of these phenomena need to be identified and stopped before the development reaches a crises.

Theoretical conceptualization of TD: A practical perspective

The Technical Debt (TD) metaphor has been used as a way to manage and communicate long-term consequences that some technical decisions may cause. Although intuitive, a lack of practical analysis and demonstrations defers its dissemination over the software community. This exploratory study applied two research methods to characterize the effects associated with a TD item during six years of a real software project lifecycle. First, a quantitative analysis was carried out to characterize the TD item in terms of concrete numbers. Then, Grounded Theory techniques were used to identify categories, properties and their relations, which could together provide a fuller definition of the TD metaphor. The resultant Grounded Theory, in the form of a concept map, confirmed some elements already identified by the technical literature, but also raised up new concepts that should be considered during analysis of TD items. Thus, this work contributes to the effort in building a formal theory about TD and provides directions to assist the work of developers/managers who intend to identify and monitor TD items in their projects, given the practical nature of this study.