Technical Debt Prioritization: State of the Art. A Systematic Literature Review

Background. Software companies need to manage and refactor Technical Debt issues. Therefore, it is necessary to understand if and when refactoring Technical Debt should be prioritized with respect to developing features or fixing bugs. Objective. The goal of this study is to investigate the existing body of knowledge in software engineering to understand what Technical Debt prioritization approaches have been proposed in research and industry. Method. We conducted a Systematic Literature Review among 384 unique papers published until 2018, following a consolidated methodology applied in Software Engineering. We included 38 primary studies. Results. Different approaches have been proposed for Technical Debt prioritization, all having different goals and optimizing on different criteria. The proposed measures capture only a small part of the plethora of factors used to prioritize Technical Debt qualitatively in practice. We report an impact map of such factors. However, there is a lack of empirical and validated set of tools. Conclusion. We observed that technical Debt prioritization research is preliminary and there is no consensus on what are the important factors and how to measure them. Consequently, we cannot consider current research conclusive and in this paper, we outline different directions for necessary future investigations

Redefining legacy : a technical debt perspective

Organisations that manage legacy systems at scale, such as those found within large government agencies and commercial enterprises, face a set of unique challenges. They manage complex software landscapes that have evolved over decades. Current conceptual definitions of legacy systems give practitioners limited insights that can inform their daily work. In this research, we compare conceptual definitions of large-scale legacy and technical debt. We hypothesise that large-scale legacy reflects an accumulation of technical debt that has never been through a remediation phase. To pursue this hypothesis, we identified the following question: How do practitioners describe their experience of managing large-scale legacy landscapes? We conducted 16 semi-structured open-ended, recorded and transcribed interviews with industry practitioners from 4 government organisations and 9 large enterprises involved with the maintenance and migration of large-scale legacy systems. A snowball sampling technique was used to identify participants. We adopted an approach informed by grounded theory. There was consensus among the practitioners in our study that the landscape is fragmented and inflexible, consisting of many dispersed and fragile applications. Practitioners report challenges with shifting paradigms from batch processing to near real-time customer-focused information systems. Our findings show there is overlap between challenges experienced by participants and symptoms typified by technical debt. We identify a novel type of technical debt, ``Ecosystem Debt'' which arises from the scale, and age, of many large-scale legacy applications. By positioning Legacy within the context of Technical Debt, practitioners have a more concrete understanding of the state of the systems they maintain

How to get away with technical debt: An explorative multiple-case study on autonomous teams and technical debt management

Technical debt (TD) is constantly accumulating throughout software development processes. In many autonomous teams this technical debt will damage and injure the process, prohibiting them from adding new functionalities to their products. Tech companies must therefore understand how they can manage TD to avoid getting stuck fixing bad code. In the research on technical debt management (TDM), there seems to be a lack of empirical studies that examine how TD is managed in autonomous teams. Some frameworks are developed with the purpose of investigating TDM but lack the empirical validation and reliability. This study investigates how autonomous teams actively manage technical debt, by conducting a multiple-case study in a Norwegian fintech company. The teams are studied by utilizing the TDM framework, measuring autonomous teams’ degree of maturity within different TDM activities in order to understand their current state of practice and how to further improve these. The study found that all autonomous teams practiced TDM, but to various extents. Some teams had structured processes, while others had no clear strategies. Most of the teams were ranked with what the framework call “received level of maturity”, and conducted TDM activities occasionally based on their current needs. The study also found challenges related to the TDM frameworks maturity levels relation to TDM success, and identified that TDM activities ranked as highly mature did not necessarily translate into higher TDM success. The study identified a need for the TDM framework to be further empirically tested and iterated on for it to work as a an accurate tool for understanding and improving autonomous teams’ TDM processes. Keywords: agile software development, autonomous teams, technical debt, technical debt management, case stud

Impact of Opportunistic Reuse Practices to Technical Debt

Technical debt (TD) has been recognized as an important quality problem for both software architecture and code. The evolution of TD techniques over the past years has led to a number of research and commercial tools. In addition, the increasing trend of opportunistic reuse (as opposed to systematic reuse), where developers reuse code assets in popular repositories, is changing the way components are selected and integrated into existing systems. However, reusing software opportunistically can lead to a loss of quality and induce TD, especially when the architecture is changed in the process. However, to the best of our knowledge, no studies have investigated the impact of opportunistic reuse in TD. In this paper, we carry out an exploratory study to investigate to what extent reusing components opportunistically negatively affects the quality of systems. We use one commercial and one research tool to analyze the TD ratios of three case systems, before and after opportunistically extending them with open-source software.Peer reviewe

Robotic Process Automation from the Design-Capital Perspective – Effects on Technical Debt and Digital Options

Robotic process automation (RPA) is an instantiation of lightweight automation that allows organizations to automate manual business processes quickly and at low cost without modifying the organization’s underlying deep information-systems structures. While RPA endows organizations with digital options (e.g., automation ability, cost savings), its implementation is bound to incur technical debt (i.e., accumulate unwarranted complexity in the IT architecture). The paper reports on an action research study shedding light on how RPA ties in with these two notions of a firm’s design capital: digital options and technical debt. Findings indicate that RPA can create digital options through improvements in knowledge reach, knowledge richness, and process richness. These benefits come at the cost of accumulating technical debt which stems from additional technical complexity and maintenance obligations