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

Addressing Software-Based, Platform Interoperability Risks in Defense Systems by Using Distressed Debt Financial Strategies: A Technical Debt Mitigation Concept

This concept paper explores an innovative approach to detecting and managing software vulnerabilities in cyber-physical defense systems. Software-based vulnerabilities that hinder or preclude the maintainability and evolvability of combat systems are a pernicious form of technical debt that threaten all cyber-physical systems. The risks associated with technical debt across increasingly interdependent DoD cyber-physical systems will accelerate if left unchecked. Without changes in acquisition and maintenance practices, we can foresee cascading, potentially catastrophic cross-system failures. To illustrate the risk and possible solutions, we focus on the software embedded in combat systems that are subject to ongoing modernization efforts that extend their applicability to evolving operations. Our research revealed that software vulnerabilities in critical combat systems can threaten the reliability and readiness of those systems. These vulnerabilities provide an opportunity for the defense acquisition communities to create a new capability within their organizations, an Acquisition Technical Debt Team (ATDT) to help detect, manage, and mitigate technical debt. We explore risk classification by including interoperability into risk evaluation schemas. We then apply common distressed debt management models to suggest when and how the ATDT might help manage and mitigate technical debt to help rehabilitate an ailing system.Prepared for the Naval Postgraduate School, Monterey, CA 93943.Naval Postgraduate SchoolApproved for public release; distribution is unlimited.Approved for public release; distribution is unlimited

Further Investigation of the Survivability of Code Technical Debt Items

Context: 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 artefacts. 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 analysing two industrial cases and 31 open-source systems from Apache Foundation. Method: We analysed 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.Comment: Submitted to the Journal of Software: Evolution and Process (JSME

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 of 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 of 557 unique papers published until 2019, following a consolidated methodology applied in software engineering. We included 44 primary studies.Results. Different approaches have been proposed for Technical Debt prioritization, all having different goals and proposing optimization regarding different criteria. The proposed measures capture only a small part of the plethora of factors used to prioritize Technical Debt qualitatively in practice. We present 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 the important factors are and how to measure them. Consequently, we cannot consider current research\ua0conclusive. In this paper, we therefore outline different directions for necessary future investigations

Managing Technical Debt in Agile Software Development Projects

One of the key reasons that agile software development methods have gained popularity in recent years is because they enable organizations to produce software quickly to meet the needs of various stakeholders. However, this focus on delivering software quickly often encourages practitioners to incur technical debt – design or implementation constructs that are expedient in the short term but set up a technical context that can make future changes more costly or impossible. Worldwide, technical debt is estimated to be a trillion-dollar problem. This has prompted significant interest from both researchers and practitioners. In this dissertation, I present two essays that advance our knowledge of the causes of technical debt in agile software development projects and that offer potential solutions to manage the most important of these causes of technical debt. In my first essay, I conduct a ranking-type Delphi study of information technology (IT) project managers and software developers to identify and prioritize the most important causes of technical debt in agile software development projects. The findings from this study provide a verified list of 55 causes of technical debt in agile software development projects and offer 13 potential techniques to manage the causes of technical debt that were most important to the IT project managers and software developers in this study. In my second essay, I conduct a randomized experiment to examine the impact of software developers’ construal level, a cognitive process, on the unintentional accumulation of technical debt in software development projects. The findings from this experiment suggest that software developers at a high construal level are more likely to focus on developing the architecture or design than software developers at a low construal level. Collectively, the findings from these two essays deepen our understanding of the intentional and unintentional causes of technical debt in agile software development projects. Further, the findings offer potential techniques to manage the most important causes of technical debt for IT project managers and software developers

Embracing Technical Debt, from a Startup Company Perspective

Software\ua0 startups\ua0 are\ua0 typically\ua0 under\ua0 extreme pressure to get to market quickly with limited resources and high uncertainty.\ua0 This\ua0 pressure\ua0 and\ua0 uncertainty\ua0 is\ua0 likely\ua0 to\ua0 cause startups to accumulate technical debt as they make decisions that are more focused on the short-term than the long-term health of the codebase. However, most research on technical debt has been focused\ua0 on\ua0 more\ua0 mature\ua0 software\ua0 teams,\ua0 who\ua0 may\ua0 have\ua0 less pressure\ua0 and,\ua0 therefore,\ua0 reason\ua0 about\ua0 technical\ua0 debt\ua0 very differently\ua0 than\ua0 software\ua0 startups.\ua0 In\ua0 this\ua0 study,\ua0 we\ua0 seek\ua0 to understand\ua0 the\ua0 organizational\ua0 factors\ua0 that\ua0 lead\ua0 to\ua0 and\ua0 the benefits\ua0 and\ua0 challenges\ua0 associated\ua0 with\ua0 the\ua0 intentional accumulation\ua0 of\ua0 technical\ua0 debt\ua0 in\ua0 software\ua0 startups.\ua0 We interviewed 16 professionals involved in seven different software startups.\ua0 We\ua0 find\ua0 that\ua0 the\ua0 startup\ua0 phase,\ua0 the\ua0 experience\ua0 of\ua0 the developers,\ua0 software\ua0 knowledge\ua0 of\ua0 the\ua0 founders,\ua0 and\ua0 level\ua0 of employee\ua0 growth\ua0 are\ua0 some\ua0 of\ua0 the\ua0 organizational\ua0 factors\ua0 that influence\ua0 the\ua0 intentional\ua0 accumulation\ua0 of\ua0 technical\ua0 debt.\ua0 In addition,\ua0 we\ua0 find\ua0 the\ua0 software\ua0 startups\ua0 are\ua0 typically\ua0 driven\ua0 to achieve\ua0 a\ua0 “good\ua0 enough\ua0 level,”\ua0 and\ua0 this\ua0 guides\ua0 the\ua0 amount\ua0 of technical debt that they intentionally accumulate to balance the benefits\ua0 of\ua0 speed\ua0 to\ua0 market\ua0 and\ua0 reduced\ua0 resources\ua0 with\ua0 the challenges of later addressing technical debt

Hitting the Bullseye: The Influence of Technical Debt on the Accuracy of Effort Estimation in Agile Projects

As firms rapidly develop solutions in order to increase revenue and market share, software development decisions considered to be temporary shortcuts and/or compromises may be implemented. These shortcuts represent “technical debt,” a metaphor which succinctly describes a software solution that should be “paid in full” or remediated in the future. Software architects and developers intend to resolve the “debt” in future product releases, but practitioners recognize that the challenge of always innovating may indefinitely postpone this remediation effort. Further, the accumulation of technical debt may have long term impact on the product’s maintainability by the software development teams and, consequently, impact the effort estimate delivered to management for forecasting product delivery timelines and product revenue expectations. While there are multiple publications that have studied effort estimation in traditional and agile software development strategies, there is limited research which considers technical debt during the estimation effort. As a result, the purpose of this dissertation is to design and propose a research model intended to determine whether or not the consideration of technical debt during the effort estimation process will improve the accuracy of the effort estimate in an agile project

Technical Debt: An empirical investigation of its harmfulness and on management strategies in industry

Background: In order to survive in today\u27s fast-growing and ever fast-changing business environment, software companies need to continuously deliver customer value, both from a short- and long-term perspective. However, the consequences of potential long-term and far-reaching negative effects of shortcuts and quick fixes made during the software development lifecycle, described as Technical Debt (TD), can impede the software development process.Objective: The overarching goal of this Ph.D. thesis is twofold. The first goal is to empirically study and understand in what way and to what extent, TD influences today’s software development work, specifically with the intention to provide more quantitative insight into the field. Second, to understand which different initiatives can reduce the negative effects of TD and also which factors are important to consider when implementing such initiatives.Method: To achieve the objectives, a combination of both quantitative and qualitative research methodologies are used, including interviews, surveys, a systematic literature review, a longitudinal study, analysis of documents, correlation analysis, and statistical tests. In seven of the eleven studies included in this Ph.D. thesis, a combination of multiple research methods are used to achieve high validity.Results: We present results showing that software suffering from TD will cause various negative effects on both the software and the developing process. These negative effects are illustrated from a technical, financial, and a developer’s working situational perspective. These studies also identify several initiatives that can be undertaken in order to reduce the negative effects of TD.Conclusion: The results show that software developers report that they waste 23% of their working time due to experiencing TD and that TD required them to perform additional time-consuming work activities. This study also shows that, compared to all types of TD, architectural TD has the greatest negative impact on daily software development work and that TD has negative effects on several different software quality attributes. Further, the results show that TD reduces developer morale. Moreover, the findings show that intentionally introducing TD in startup companies can allow the startups to cut development time, enabling faster feedback and increased revenue, preserve resources, and decrease risk and thereby contribute to beneficial\ua0effects. This study also identifies several initiatives that can be undertaken in order to reduce the negative effects of TD, such as the introduction of a tracking process where the TD items are introduced in an official backlog. The finding also indicates that there is an unfulfilled potential regarding how managers can influence the manner in which software practitioners address TD

Collaboration Strategies to Reduce Technical Debt

Inadequate software development collaboration processes can allow technical debt to accumulate increasing future maintenance costs and the chance of system failures. The purpose of this qualitative case study was to explore collaboration strategies software development leaders use to reduce the amount of technical debt created by software developers. The study population was software development leaders experienced with collaboration and technical debt at a large health care provider in the state of California. The data collection process included interviews with 8 software development leaders and reviewing 19 organizational documents relating to software development methods. The extended technology acceptance model was used as the conceptual framework to better understand the social and cognitive influences on the perceived usefulness of collaboration in reducing technical debt. An inductive analysis of the data was used for coding, triangulation, and identifying themes related to the use of collaboration strategies to reduce technical debt. Prominent themes included using collaboration at all stages of development, using continuous verification processes, promoting a participatory culture, and using tools to support distributed teams. The study findings showed an environment that promotes collaboration, a culture that encourages participation, and accessibility to collaborative tools that may reduce technical debt in software projects. The results of this study may contribute to positive social change by demonstrating how individuals with diverse backgrounds and different perspectives can work together to improve critical software that people depend on every day