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

Proposta de modelo ?nico para prioriza??o de d?vida t?cnica

Over the years, software has become more and more present in the people?s and compani?es daily life. The software development companies aiming to understand customer needs, often investing in optimization, improving the product quality. However, software development companies have been dealing with limited amounts of time and resources, which have to be applied to generate in a short term financial gains and in addition they also have to develop features that satisfy the customers. Therefore, managers and developers focus other aspects than quality to establish a balance between the objectives, features and functionalities of the product, development can be taken shortcuts because of the short time to prioritize this over the quality. In 1992, the term technical debt was cited by Ward Cunningham to reflect the scenario in which to accelerate the development of software would require the writing of an immature code, thereby generating a debt. This metaphor gradually extended to other parts of the software, generally reflecting the immature, inadequate, or incomplete artifacts present in the development life cycle. Due to limited resources, identified technical debt items should be prioritized, seeking to classify and rank debts from technical factors or needs. Although there are some studies on technical debt prioritization, there are still many gaps on how to prioritize a technical debt item. So, it is important to elaborate new models to help developers to prioritize technical debt items, seeking to assist in decision making and aiming to clarify to entrepreneurs the real benefits linked to technical improvements. The objective of this study is to identify and categorize the technical debt prioritization approaches in the literature and, finally, a unique model of prioritization was proposed based on the characteristics derived from these studies. The approach developed is intended to prioritize classes affected by code smells, which are design problems at the source code level of a system and can indicate technical debt points. The model has six phases of classification, each phase representing specific ranking metrics. At the end of the prioritization process, the classes smelly with the highest priority of correction are obtained in relation to the considered criteria. The proposed model was validated with specialists in the area in order to verify its contribution and relevance.Com o passar dos anos, os softwares tornaram-se cada vez mais presentes no cotidiano de pessoas e empresas. As ind?strias desenvolvedoras, visando atender as necessidades dos seus clientes investem frequentemente em otimiza??o, buscando melhorias na qualidade do produto final. Por?m, as ind?strias de desenvolvimento de software lidam com valores limitados de tempo e recursos, fazendo com que essas tenham que aplic?-los de forma a gerar um retorno financeiro a curto prazo e ao mesmo tempo, desenvolvendo funcionalidades que possam satisfazer os clientes. Com isso, aspectos internos de qualidade s?o alvos de indecis?o por parte dos gerentes e desenvolvedores, retratando o contexto da d?vida t?cnica, em que para se estabelecer um equil?brio entre os objetivos, recursos e funcionalidades do produto, atalhos de desenvolvimento podem ser tomados a curto prazo. Em 1992, o termo d?vida t?cnica foi citado por Ward Cunningham para refletir o cen?rio em que para acelerar o desenvolvimento de software seria necess?rio a escrita de um c?digo imaturo, gerando-se assim uma d?vida. Essa met?fora estendeu-se gradualmente a outras partes do software, refletindo de maneira geral aos artefatos imaturos, inadequados ou incompletos presentes no ciclo de vida de desenvolvimento. Devido aos recursos limitados, os itens de d?vida t?cnica identificados devem ser priorizados, buscando classificar e ranquear as d?vidas a partir de fatores ou necessidades t?cnicas. Embora j? existam alguns estudos sobre prioriza??o, ainda existem muitos desafios em como definir a prioridade de um item de d?vida t?cnica. Por isso, ? necess?ria a elabora??o de novos modelos para priorizar os itens com sucesso, buscando auxiliar na tomada de decis?o e visando esclarecer aos empres?rios os reais benef?cios vinculados ?s melhorias t?cnicas. O objetivo deste trabalho ? identificar e categorizar as abordagens de prioriza??o de d?vida t?cnica existentes na literatura e por fim, prop?s-se um modelo ?nico de prioriza??o baseado nas caracter?sticas oriundas desses estudos. A abordagem desenvolvida tem como objetivo priorizar classes afetadas por code smells, que s?o problemas de design ao n?vel do c?digo-fonte de um sistema e podem indicar pontos de d?vida t?cnica. O modelo possui seis fases de classifica??o, sendo que cada fase representa m?tricas espec?ficas de ranqueamento. No final do processo de prioriza??o, obt?m-se as classes smelly com maior prioridade de corre??o em rela??o aos crit?rios considerados. O modelo proposto foi validado com especialistas na ?rea a fim de verificar sua contribui??o e relev?ncia

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