Technical Debt Prioritization: State of the Art. A Systematic Literature Review
---
paper_title: An empirically developed method to aid decisions on architectural technical debt refactoring: AnaConDebt

paper_content:

Architectural Technical Debt is regarded as sub-optimal architectural solutions that need to be refactored in order to avoid the payment of a costly interest in the future. However, decisions on if and when to refactor architecture are extremely important and difficult to take, since changing software at the architectural level is quite expensive. Therefore it is important, for software organizations, to have methods and tools that aid architects and managers to understand if Architecture Technical Debt will generate a costly and growing interest to be paid or not. Current knowledge, especially empirically developed and evaluated, is quite scarce. In this paper we developed and evaluated a method, AnaConDebt, by analyzing, together with several practitioners, 12 existing cases of Architecture Debt in 6 companies. The method has been refined several times in order to be useful and effective in practice. We also report the evaluation of the method with a final case, for which we present anonymized results and subsequent refactoring decisions. The method consists of several components that need to be analyzed, combining the theoretical Technical Debt framework and the practical experience of the practitioners, in order to identify the key factors involved in the growth of interest. The output of the method shows summarized indicators that visualizes the factors in a useful way for the stakeholders. This analysis aids the practitioners in deciding on if and when to refactor Architectural Technical Debt items. The method has been evaluated and has been proven useful to support the architects into systematically analyze and decide upon a case.
---
paper_title: Using technical debt data in decision making: Potential decision approaches

paper_content:

The management of technical debt ultimately requires decision making -- about incurring, paying off, or deferring technical debt instances. This position paper discusses several existing approaches to complex decision making, and suggests that exploring their applicability to technical debt decision making would be a worthwhile subject for further research.
---
paper_title: Managing Technical Debt in Software Engineering (Dagstuhl Seminar 16162)

paper_content:

This report documents the program and outcomes of Dagstuhl Seminar 16162, “Managing Technical Debt in Software Engineering.” We summarize the goals and format of the seminar, results from the breakout groups, a definition for technical debt, a draft conceptual model, and a research road map that culminated from the discussions during the seminar. The report also includes the abstracts of the talks presented at the seminar and summaries of open discussions.
---
paper_title: A systematic mapping study on technical debt and its management

paper_content:

A systematic mapping study on technical debt and its management.Ninety-four papers are finally selected for data extraction and analysis.Technical debt was classified into 10 types.Eight activities of and 29 tools for technical debt management were identified.Code-related technical debt has gained the most attention. ContextTechnical debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefit but may hurt the long-term health of a software system. ObjectiveThis work aims at collecting studies on TD and TD management (TDM), and making a classification and thematic analysis on these studies, to obtain a comprehensive understanding on the TD concept and an overview on the current state of research on TDM. MethodA systematic mapping study was performed to identify and analyze research on TD and its management, covering publications between 1992 and 2013. ResultsNinety-four studies were finally selected. TD was classified into 10 types, 8 TDM activities were identified, and 29 tools for TDM were collected. ConclusionsThe term "debt" has been used in different ways by different people, which leads to ambiguous interpretation of the term. Code-related TD and its management have gained the most attention. There is a need for more empirical studies with high-quality evidence on the whole TDM process and on the application of specific TDM approaches in industrial settings. Moreover, dedicated TDM tools are needed for managing various types of TD in the whole TDM process.
---
paper_title: Technical debt cripples software developer productivity: a longitudinal study on developers' daily software development work

paper_content:

Software companies need to continuously deliver customer value, both from a short- and long-term perspective. However, software development can be impeded by what has been described as Technical Debt (TD). The aim of this study is to explore the negative consequences of TD in terms of wasted software development time. This study also investigates on which additional activities this wasted time is spent and whether different types of TD impact the wasted time differently. This study also sets out to examine the benefits of tracking and communicating the amount of wasted time, both from a developer's and manager's perspective. This paper reports the results of a longitudinal study, surveying 43 software developers, together with follow-up interviews with 16 industrial software practitioners. The analysis of the reported wasted time revealed that developers waste, on average, 23% of their development time due to TD and that they are frequently forced to introduce new TD due to already existing TD. The most common activity on which additional time is spent is performing additional testing.
---
paper_title: Embracing Technical Debt, from a Startup Company Perspective

paper_content:

Software startups are typically under extreme pressure to get to market quickly with limited resources and high uncertainty. This pressure and uncertainty is likely to 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 on more mature software teams, who may have less pressure and, therefore, reason about technical debt very differently than software startups. In this study, we seek to understand the organizational factors that lead to and the benefits and challenges associated with the intentional accumulation of technical debt in software startups. We interviewed 16 professionals involved in seven different software startups. We find that the startup phase, the experience of the developers, software knowledge of the founders, and level of employee growth are some of the organizational factors that influence the intentional accumulation of technical debt. In addition, we find the software startups are typically driven to achieve a "good enough level," and this guides the amount of technical debt that they intentionally accumulate to balance the benefits of speed to market and reduced resources with the challenges of later addressing technical debt.
---
paper_title: Reducing Friction in Software Development

paper_content:

Software is being produced so fast that its growth hinders its sustainability. Technical debt, which encompasses internal software quality, evolution and maintenance, reengineering, and economics, is growing such that its management is becoming the dominant driver of software engineering progress. It spans the software engineering life cycle, and its management capitalizes on recent advances in fields such as source code analysis, quality measurement, and project management. Managing technical debt will become an investment activity applying economic theories. It will effectively address the architecture level and will offer specific processes and tools employing data science and analytics to support decision making. It will also be an essential part of the software engineering curriculum. Getting ahead of the software quality and innovation curve will inevitably involve establishing technical-debt management as a core software engineering practice. This article is part of a special issue on the Future of Software Engineering.
---
paper_title: A systematic mapping study on technical debt and its management

paper_content:

A systematic mapping study on technical debt and its management.Ninety-four papers are finally selected for data extraction and analysis.Technical debt was classified into 10 types.Eight activities of and 29 tools for technical debt management were identified.Code-related technical debt has gained the most attention. ContextTechnical debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefit but may hurt the long-term health of a software system. ObjectiveThis work aims at collecting studies on TD and TD management (TDM), and making a classification and thematic analysis on these studies, to obtain a comprehensive understanding on the TD concept and an overview on the current state of research on TDM. MethodA systematic mapping study was performed to identify and analyze research on TD and its management, covering publications between 1992 and 2013. ResultsNinety-four studies were finally selected. TD was classified into 10 types, 8 TDM activities were identified, and 29 tools for TDM were collected. ConclusionsThe term "debt" has been used in different ways by different people, which leads to ambiguous interpretation of the term. Code-related TD and its management have gained the most attention. There is a need for more empirical studies with high-quality evidence on the whole TDM process and on the application of specific TDM approaches in industrial settings. Moreover, dedicated TDM tools are needed for managing various types of TD in the whole TDM process.
---
paper_title: Decision Criteria for the Payment of Technical Debt in Software Projects: A Systematic Mapping Study

paper_content:

The term Technical Debt (TD) is used to describe the debt that a development team incurs when it takes shortcuts in the software development process, but that may increase the complexity and maintenance cost in the long-term. If a development team does not manage TD, this debt can cause significant long-term problems such as high maintenance costs. An important goal of the management of the debt is to evaluate the appropriate time to pay a TD item and to effectively apply decision-making criteria to balance the short-term benefits against long-term costs. However, although there are different studies that have proposed strategies for the management of TD, decision criteria are often discussed in the background and, sometimes, they are not even mentioned. Thus, the purpose of this work is to identify, by performing a systematic mapping study of the literature, decision-making criteria that have been proposed to support the management of TD. We identified 14 decision-making criteria that can be used by development teams to prioritize the payment of TD items and a list of types of debt related to the criteria. In addition, the results show possible gaps where further research may be performed.
---
paper_title: An exploration of technical debt

paper_content:

Context: Whilst technical debt is considered to be detrimental to the long term success of software development, it appears to be poorly understood in academic literature. The absence of a clear definition and model for technical debt exacerbates the challenge of its identification and adequate management, thus preventing the realisation of technical debt's utility as a conceptual and technical communication device. Objective: To make a critical examination of technical debt and consolidate understanding of the nature of technical debt and its implications for software development. Method: An exploratory case study technique that involves multivocal literature review, supplemented by interviews with software practitioners and academics to establish the boundaries of the technical debt phenomenon. Result: A key outcome of this research is the creation of a theoretical framework that provides a holistic view of technical debt comprising a set of technical debts dimensions, attributes, precedents and outcomes, as well as the phenomenon itself and a taxonomy that describes and encompasses different forms of the technical debt phenomenon. Conclusion: The proposed framework provides a useful approach to understanding the overall phenomenon of technical debt for practical purposes. Future research should incorporate empirical studies to validate heuristics and techniques that will assist practitioners in their management of technical debt.
---
paper_title: Analyzing the concept of technical debt in the context of agile software development: A systematic literature review

paper_content:

Abstract Context Technical debt (TD) is a metaphor that is used to communicate the consequences of poor software development practices to non-technical stakeholders. In recent years, it has gained significant attention in agile software development (ASD). Objective The purpose of this study is to analyze and synthesize the state of the art of TD, and its causes, consequences, and management strategies in the context of ASD. Research Method Using a systematic literature review (SLR), 38 primary studies, out of 346 studies, were identified and analyzed. Results We found five research areas of interest related to the literature of TD in ASD. Among those areas, “managing TD in ASD” received the highest attention, followed by “architecture in ASD and its relationship with TD”. In addition, eight categories regarding the causes and five categories regarding the consequences of incurring TD in ASD were identified. “Focus on quick delivery” and “architectural and design issues” were the most popular causes of incurring TD in ASD. “Reduced productivity”, “system degradation” and “increased maintenance cost” were identified as significant consequences of incurring TD in ASD. Additionally, we found 12 strategies for managing TD in the context of ASD, out of which “refactoring” and “enhancing the visibility of TD” were the most significant. Conclusion The results of this study provide a structured synthesis of TD and its management in the context of ASD as well as potential research areas for further investigation.
---
paper_title: A systematic mapping study on technical debt and its management

paper_content:

A systematic mapping study on technical debt and its management.Ninety-four papers are finally selected for data extraction and analysis.Technical debt was classified into 10 types.Eight activities of and 29 tools for technical debt management were identified.Code-related technical debt has gained the most attention. ContextTechnical debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefit but may hurt the long-term health of a software system. ObjectiveThis work aims at collecting studies on TD and TD management (TDM), and making a classification and thematic analysis on these studies, to obtain a comprehensive understanding on the TD concept and an overview on the current state of research on TDM. MethodA systematic mapping study was performed to identify and analyze research on TD and its management, covering publications between 1992 and 2013. ResultsNinety-four studies were finally selected. TD was classified into 10 types, 8 TDM activities were identified, and 29 tools for TDM were collected. ConclusionsThe term "debt" has been used in different ways by different people, which leads to ambiguous interpretation of the term. Code-related TD and its management have gained the most attention. There is a need for more empirical studies with high-quality evidence on the whole TDM process and on the application of specific TDM approaches in industrial settings. Moreover, dedicated TDM tools are needed for managing various types of TD in the whole TDM process.
---
paper_title: Managing architectural technical debt: A unified model and systematic literature review

paper_content:

Large Software Companies need to support the continuous and fast delivery of customer value in both the short and long term. However, this can be impeded if the evolution and maintenance of existing systems is hampered by what has been recently termed Technical Debt (TD). Specifically, Architectural TD has received increased attention in the last few years due to its significant impact on system success and, left unchecked, it can cause expensive repercussions. It is therefore important to understand the underlying factors of architectural TD. With this as background, there is a need for a descriptive model to illustrate and explain different architectural TD issues. The aim of this study is to synthesize and compile research efforts with the goal of creating new knowledge with a specific interest in the architectural TD field. The contribution of this paper is the presentation of a novel descriptive model, providing a comprehensive interpretation of the architectural TD phenomenon. This model categorizes the main characteristics of architectural TD and reveals their relations. The results show that, by using this model, different stakeholders could increase the system's success rate, and lower the rate of negative consequences, by raising awareness about architectural TD.
---
paper_title: Guidelines for snowballing in systematic literature studies and a replication in software engineering

paper_content:

Background: Systematic literature studies have become common in software engineering, and hence it is important to understand how to conduct them efficiently and reliably. Objective: This paper presents guidelines for conducting literature reviews using a snowballing approach, and they are illustrated and evaluated by replicating a published systematic literature review. Method: The guidelines are based on the experience from conducting several systematic literature reviews and experimenting with different approaches. Results: The guidelines for using snowballing as a way to search for relevant literature was successfully applied to a systematic literature review. Conclusions: It is concluded that using snowballing, as a first search strategy, may very well be a good alternative to the use of database searches.
---
paper_title: A systematic review of systematic review process research in software engineering

paper_content:

Context: Many researchers adopting systematic reviews (SRs) have also published papers discussing problems with the SR methodology and suggestions for improving it. Since guidelines for SRs in software engineering (SE) were last updated in 2007, we believe it is time to investigate whether the guidelines need to be amended in the light of recent research. Objective: To identify, evaluate and synthesize research published by software engineering researchers concerning their experiences of performing SRs and their proposals for improving the SR process. Method: We undertook a systematic review of papers reporting experiences of undertaking SRs and/or discussing techniques that could be used to improve the SR process. Studies were classified with respect to the stage in the SR process they addressed, whether they related to education or problems faced by novices and whether they proposed the use of textual analysis tools. Results: We identified 68 papers reporting 63 unique studies published in SE conferences and journals between 2005 and mid-2012. The most common criticisms of SRs were that they take a long time, that SE digital libraries are not appropriate for broad literature searches and that assessing the quality of empirical studies of different types is difficult. Conclusion: We recommend removing advice to use structured questions to construct search strings and including advice to use a quasi-gold standard based on a limited manual search to assist the construction of search stings and evaluation of the search process. Textual analysis tools are likely to be useful for inclusion/exclusion decisions and search string construction but require more stringent evaluation. SE researchers would benefit from tools to manage the SR process but existing tools need independent validation. Quality assessment of studies using a variety of empirical methods remains a major problem.
---
paper_title: A systematic mapping study on technical debt and its management

paper_content:

A systematic mapping study on technical debt and its management.Ninety-four papers are finally selected for data extraction and analysis.Technical debt was classified into 10 types.Eight activities of and 29 tools for technical debt management were identified.Code-related technical debt has gained the most attention. ContextTechnical debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefit but may hurt the long-term health of a software system. ObjectiveThis work aims at collecting studies on TD and TD management (TDM), and making a classification and thematic analysis on these studies, to obtain a comprehensive understanding on the TD concept and an overview on the current state of research on TDM. MethodA systematic mapping study was performed to identify and analyze research on TD and its management, covering publications between 1992 and 2013. ResultsNinety-four studies were finally selected. TD was classified into 10 types, 8 TDM activities were identified, and 29 tools for TDM were collected. ConclusionsThe term "debt" has been used in different ways by different people, which leads to ambiguous interpretation of the term. Code-related TD and its management have gained the most attention. There is a need for more empirical studies with high-quality evidence on the whole TDM process and on the application of specific TDM approaches in industrial settings. Moreover, dedicated TDM tools are needed for managing various types of TD in the whole TDM process.
---
paper_title: A systematic mapping study on technical debt and its management

paper_content:

A systematic mapping study on technical debt and its management.Ninety-four papers are finally selected for data extraction and analysis.Technical debt was classified into 10 types.Eight activities of and 29 tools for technical debt management were identified.Code-related technical debt has gained the most attention. ContextTechnical debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefit but may hurt the long-term health of a software system. ObjectiveThis work aims at collecting studies on TD and TD management (TDM), and making a classification and thematic analysis on these studies, to obtain a comprehensive understanding on the TD concept and an overview on the current state of research on TDM. MethodA systematic mapping study was performed to identify and analyze research on TD and its management, covering publications between 1992 and 2013. ResultsNinety-four studies were finally selected. TD was classified into 10 types, 8 TDM activities were identified, and 29 tools for TDM were collected. ConclusionsThe term "debt" has been used in different ways by different people, which leads to ambiguous interpretation of the term. Code-related TD and its management have gained the most attention. There is a need for more empirical studies with high-quality evidence on the whole TDM process and on the application of specific TDM approaches in industrial settings. Moreover, dedicated TDM tools are needed for managing various types of TD in the whole TDM process.
---
paper_title: Guidelines for snowballing in systematic literature studies and a replication in software engineering

paper_content:

Background: Systematic literature studies have become common in software engineering, and hence it is important to understand how to conduct them efficiently and reliably. Objective: This paper presents guidelines for conducting literature reviews using a snowballing approach, and they are illustrated and evaluated by replicating a published systematic literature review. Method: The guidelines are based on the experience from conducting several systematic literature reviews and experimenting with different approaches. Results: The guidelines for using snowballing as a way to search for relevant literature was successfully applied to a systematic literature review. Conclusions: It is concluded that using snowballing, as a first search strategy, may very well be a good alternative to the use of database searches.
---
paper_title: A systematic review of systematic review process research in software engineering

paper_content:

Context: Many researchers adopting systematic reviews (SRs) have also published papers discussing problems with the SR methodology and suggestions for improving it. Since guidelines for SRs in software engineering (SE) were last updated in 2007, we believe it is time to investigate whether the guidelines need to be amended in the light of recent research. Objective: To identify, evaluate and synthesize research published by software engineering researchers concerning their experiences of performing SRs and their proposals for improving the SR process. Method: We undertook a systematic review of papers reporting experiences of undertaking SRs and/or discussing techniques that could be used to improve the SR process. Studies were classified with respect to the stage in the SR process they addressed, whether they related to education or problems faced by novices and whether they proposed the use of textual analysis tools. Results: We identified 68 papers reporting 63 unique studies published in SE conferences and journals between 2005 and mid-2012. The most common criticisms of SRs were that they take a long time, that SE digital libraries are not appropriate for broad literature searches and that assessing the quality of empirical studies of different types is difficult. Conclusion: We recommend removing advice to use structured questions to construct search strings and including advice to use a quasi-gold standard based on a limited manual search to assist the construction of search stings and evaluation of the search process. Textual analysis tools are likely to be useful for inclusion/exclusion decisions and search string construction but require more stringent evaluation. SE researchers would benefit from tools to manage the SR process but existing tools need independent validation. Quality assessment of studies using a variety of empirical methods remains a major problem.
---
paper_title: Empirical studies of agile software development : A systematic review

paper_content:

Agile software development represents a major departure from traditional, plan-based approaches to software engineering. A systematic review of empirical studies of agile software development up to and including 2005 was conducted. The search strategy identified 1996 studies, of which 36 were identified as empirical studies. The studies were grouped into four themes: introduction and adoption, human and social factors, perceptions on agile methods, and comparative studies. The review investigates what is currently known about the benefits and limitations of, and the strength of evidence for, agile methods. Implications for research and practice are presented. The main implication for research is a need for more and better empirical studies of agile software development within a common research agenda. For the industrial readership, the review provides a map of findings, according to topic, that can be compared for relevance to their own settings and situations.
---
paper_title: A systematic mapping study on technical debt and its management

paper_content:

A systematic mapping study on technical debt and its management.Ninety-four papers are finally selected for data extraction and analysis.Technical debt was classified into 10 types.Eight activities of and 29 tools for technical debt management were identified.Code-related technical debt has gained the most attention. ContextTechnical debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefit but may hurt the long-term health of a software system. ObjectiveThis work aims at collecting studies on TD and TD management (TDM), and making a classification and thematic analysis on these studies, to obtain a comprehensive understanding on the TD concept and an overview on the current state of research on TDM. MethodA systematic mapping study was performed to identify and analyze research on TD and its management, covering publications between 1992 and 2013. ResultsNinety-four studies were finally selected. TD was classified into 10 types, 8 TDM activities were identified, and 29 tools for TDM were collected. ConclusionsThe term "debt" has been used in different ways by different people, which leads to ambiguous interpretation of the term. Code-related TD and its management have gained the most attention. There is a need for more empirical studies with high-quality evidence on the whole TDM process and on the application of specific TDM approaches in industrial settings. Moreover, dedicated TDM tools are needed for managing various types of TD in the whole TDM process.
---
paper_title: Challenges to and Solutions for Refactoring Adoption: An Industrial Perspective

paper_content:

Refactoring is a key approach for managing technical debt. In the past few years, refactoring techniques and tools have received considerable attention from researchers and tool vendors. However, several practical challenges must be overcome to facilitate the adoption of refactoring in industrial contexts. Results from a survey at the Siemens Corporate Development Center India highlight common challenges to refactoring adoption. The article also outlines ways to address these challenges and describes key initiatives the development center is planning and launching. This article is part of a special issue on Refactoring.
---
paper_title: Defining the decision factors for managing defects: a technical debt perspective

paper_content:

Making a decision about whether to fix or defer fixing a defect is important to software projects. Deferring defects accumulates a technical debt that burdens the software team and customer with a less than optimal solution. The decision to defer fixing a defect is made by Software Change Control Boards (CCBs) based on a set of decision factors. In this paper, we evaluated the set of decision factors used by two CCBs at ABB in the context of technical debt management. The aim was to determine how a model of cost and benefits of incurring technical debt could be part of the CCB decision process. We identified the cost categories and decision factors for fixing and deferring defects as a result of interviews with CCB members. We found that the decision factors could incorporate the financial aspects when using the technical debt metaphor. We identify opportunities for further research to integrate technical debt concepts with the decision factors towards better long term outcomes.
---
paper_title: Using technical debt data in decision making: Potential decision approaches

paper_content:

The management of technical debt ultimately requires decision making -- about incurring, paying off, or deferring technical debt instances. This position paper discusses several existing approaches to complex decision making, and suggests that exploring their applicability to technical debt decision making would be a worthwhile subject for further research.
---
paper_title: JSpIRIT: a flexible tool for the analysis of code smells

paper_content:

Code smells are a popular mechanism to identify structural design problems in software systems. Since it is generally not feasible to f x all the smells arising in the code, some of them are often postponed by developer s to be resolved in the future. One reason for this decision is that the improvement of the code structure, to achieve modifability goals, requires extra effort from developer s. Therefore, they might not always spend this additional effort, particularly when they are focused on delivering customer-visible features. This postponement of code smells are seen as a source of technical debt. Furthermore, not all the code smells may be urgent to f x in the context of the system's modifability and business goals. While there are a number of tools to detect smells, they do not allow developer s to discover the most urgent smells according to their goals. In this article, we present a fexible tool to prioritize technical debt in the form of code smells. The tool is fexible to allow developer s to add new smell detection strategies and to prioritize smells, and groups of smells, based on the confguration of their manifold criteria. To illustrate this fexibility, we present an application example of our tool. The results suggest that our tool can be easily extended to be aligned with the developer's goals.
---
paper_title: Exploring the costs of technical debt management – a case study

paper_content:

Technical debt is a metaphor for delayed software maintenance tasks. Incurring technical debt may bring short-term benefits to a project, but such benefits are often achieved at the cost of extra work in future, analogous to paying interest on the debt. Currently technical debt is managed implicitly, if at all. However, on large systems, it is too easy to lose track of delayed tasks or to misunderstand their impact. Therefore, we have proposed a new approach to managing technical debt, which we believe to be helpful for software managers to make informed decisions. In this study we explored the costs of the new approach by tracking the technical debt management activities in an on-going software project. The results from the study provided insights into the impact of technical debt management on software projects. In particular, we found that there is a significant start-up cost when beginning to track and monitor technical debt, but the cost of ongoing management soon declines to very reasonable levels.
---
paper_title: The magnificent seven: towards a systematic estimation of technical debt interest

paper_content:

The interest of Technical Debt is difficult to assess. The negative effects (severity) of Technical Debt might depend on the context of the organization and the estimations might be subjective. There is a need for assessing Technical Debt interest in a more systematic way. Based on the results of previous research, we have developed and used a lightweight tool, AnaConDebt, to assess the severity of the interest of 9 Technical Debt items with the stakeholders in 3 Agile teams. The systematic and semi-automatic assessment of seven factors and their growth has been compared to the stakeholders' intuitive estimations. The results show that the outcome of the tool is very close to the estimation given by the stakeholders. The implications are that, if further data support the hypothesis, the severity of the interest can be systematically assessed by the stakeholders by estimating only seven factors in a cost-effective manner with acceptable results.
---
paper_title: A heuristic for estimating the impact of lingering defects: can debt analogy be used as a metric?

paper_content:

Background: Due to tight scheduling and limited budget, it may not be possible to resolve all the existing bugs in a current release of a software product. The accumulation of the deferred bugs in the issue tracking system are obligations (liabilities) of the software team similar to financial analogy of 'debt'. Defect debt is known as latent defects which are not resolved in the current release. Aim: In order to manage the defect debt, software managers need to be aware of the amount of debt (principal) as well as the price of the credit (interest) in their system. There are no studies in the literature to measure the principal or interest of defect debt. In this study, we propose a novel approach to identify the interest of defect debt. Methodology: We developed a heuristic to specify the interest based on three metrics: PageRank index, customer feedback and bug fixing duration. In order to investigate the feasibility of our heuristic, we employ it to two datasets that are extracted from both open source and commercial software products. We validate the heuristic using two metrics: the severity/priority of bugs, and the duration of bug fixing time. Result: The results show that 24% and 18% of the deferred bugs are high and medium impact bugs in project 1 and project 2, respectively.
---
paper_title: Prioritizing design debt investment opportunities

paper_content:

Technical debt is the technical work developers owe a system, typically caused by speeding up development, e.g. before a software release. Approaches, such as code smell detection, have been developed to identify particular kinds of debt, e.g. design debt. Up until now, code smell detection has been used to help point to components that need to be freed from debt by refactoring. To date, a number of methods have been described for finding code smells in a system. However, typical debt properties, such as the value of the debt and interest rate to be paid, have not been well established. This position paper proposes an approach to using cost/benefit analysis to prioritize technical debt reduction work by ranking the value and interest of design debt caused by god classes. The method is based on metric analysis and software repository mining and is demonstrated on a commercial software application at a mid-size development company. The results are promising: the method helps to identify which refactoring activities should be performed first because they are likely to be cheap to make yet have significant effect, and which refactorings should be postponed due to high cost and low payoff.
---
paper_title: A formal approach to technical debt decision making

paper_content:

The notion of technical debt attracts significant attention, especially in the context of reconciling architecture and agile development. However, most work on technical debt is still largely informal and if it provides a formalization it is often ad-hoc. In this paper, we provide a detailed, formal analysis of decision making on technical debt in development. Using this formalization, we show that optimal decision making is not effectively computable in real-world situations and provide several well-defined approximations that allow to handle the problem nevertheless in practical situations. Combining these approximations in a single method leads to a light-weight approach that can be effectively applied in iterative software development, including agile approaches.
---
paper_title: Assessing code smell interest probability: a case study

paper_content:

An important parameter in deciding to eliminate technical debt (TD) is the probability of a module to generate interest along software evolution. In this study, we explore code smells, which according to practitioners are the most commonly occurring type of TD in industry, by assessing the associated interest probability. As a proxy of smell interest probability we use the frequency of smell occurrences and the change proneness of the modules in which they are identified. To achieve this goal we present a case study on 47,751 methods extracted from two well-known open source projects. The results of the case study suggest that: (a) modules in which "code smells" are concentrated are more change-prone than smell-free modules, (b) there are specific types of "code smells" that are concentrated in the most change-prone modules, and (c) interest probability of code clones seems to be higher than the other two examined code smells. These results can be useful for both researchers and practitioners, in the sense that the former can focus their research on resolving "code smells" that produce more interest, and the latter can improve accordingly the prioritization of their repayment strategy and their training.
---
paper_title: Technical debt prioritization using predictive analytics

paper_content:

Recently, Technical Debt (TD) has gained popularity in the Software Engineering community to describe design decisions that allow software development teams to achieve short term benefits such as expedited release of code. Technical debt accrued should be managed to avoid the disastrous consequences of these temporary workarounds. Management of technical debt involve documenting the debt item in the backlog including some type of quantification in terms of person-hours or story points for example. Subsequently, the debt items are prioritized and addressed. Developers or project managers face problems to decide which debt is higher priority or more "problematic" and which one needs to be addressed first. This decision-making process is not standardized and is currently context dependent in most organizations. This paper bridge this gap by proposing a framework which makes use of a plethora of techniques ranging from data mining to prediction and decision models that project managers can use in their decision-making process to determine which technical debt is more critical and should be addressed first.
---
paper_title: How do software development teams manage technical debt? - An empirical study

paper_content:

Exploratory case study with empirical data from eight software development teams.Observation of various different strategies for technical debt management.Developed technical debt management framework. Technical debt (TD) is a metaphor for taking shortcuts or workarounds in technical decisions to gain short-term benefit in time-to-market and earlier software release. In this study, one large software development organization is investigated to gather empirical evidence related to the concept of technical debt management (TDM). We used the exploratory case study method to collect and analyze empirical data in the case organization by interviewing a total of 25 persons in eight software development teams. We were able to identify teams where the current strategy for TDM was only to fix TD when necessary, when it started to cause too much trouble for development. We also identified teams where the management had a systematic strategy to identify, measure and monitor TD during the development process. It seems that TDM can be associated with a similar maturity concept as software development in general. Development teams may raise their maturity by increasing their awareness and applying more advanced processes, techniques and tools in TDM. TDM is an essential part of sustainable software development, and companies have to find right approaches to deal with TD to produce healthy software that can be developed and maintained in the future.
---
paper_title: Revealing Social Debt with the CAFFEA Framework: An Antidote to Architectural Debt

paper_content:

Large software companies need a well-managed Software Architecture to support continuous and fast delivery of customer value both in the short and long term. However, this can be hindered if both evolution and maintenance of existing systems are hampered by Architectural Technical Debt. To avoid the accumulation and the costly consequences of ATD, it is critical that the responsibilities to minimize it are well understood and shared in a large software organization. In this paper, we argue that an organizational model, based on a well validated framework such as CAFFEA, can be used to reveal sub-optimalities in the social structure of the organization: in other words, it can reveal Social Debt. Such sub-optimality, according to previous work, leads to the accumulation of ATD. In conclusion, using the CAFFEA framework as an organizational analysis tool, can reveal weak spots (Social Debt) in the organization and can help preventing costly ATD and its consequences.
---
paper_title: Challenges to and Solutions for Refactoring Adoption: An Industrial Perspective

paper_content:

Refactoring is a key approach for managing technical debt. In the past few years, refactoring techniques and tools have received considerable attention from researchers and tool vendors. However, several practical challenges must be overcome to facilitate the adoption of refactoring in industrial contexts. Results from a survey at the Siemens Corporate Development Center India highlight common challenges to refactoring adoption. The article also outlines ways to address these challenges and describes key initiatives the development center is planning and launching. This article is part of a special issue on Refactoring.
---
paper_title: JSpIRIT: a flexible tool for the analysis of code smells

paper_content:

Code smells are a popular mechanism to identify structural design problems in software systems. Since it is generally not feasible to f x all the smells arising in the code, some of them are often postponed by developer s to be resolved in the future. One reason for this decision is that the improvement of the code structure, to achieve modifability goals, requires extra effort from developer s. Therefore, they might not always spend this additional effort, particularly when they are focused on delivering customer-visible features. This postponement of code smells are seen as a source of technical debt. Furthermore, not all the code smells may be urgent to f x in the context of the system's modifability and business goals. While there are a number of tools to detect smells, they do not allow developer s to discover the most urgent smells according to their goals. In this article, we present a fexible tool to prioritize technical debt in the form of code smells. The tool is fexible to allow developer s to add new smell detection strategies and to prioritize smells, and groups of smells, based on the confguration of their manifold criteria. To illustrate this fexibility, we present an application example of our tool. The results suggest that our tool can be easily extended to be aligned with the developer's goals.
---
paper_title: Exploring the costs of technical debt management – a case study

paper_content:

Technical debt is a metaphor for delayed software maintenance tasks. Incurring technical debt may bring short-term benefits to a project, but such benefits are often achieved at the cost of extra work in future, analogous to paying interest on the debt. Currently technical debt is managed implicitly, if at all. However, on large systems, it is too easy to lose track of delayed tasks or to misunderstand their impact. Therefore, we have proposed a new approach to managing technical debt, which we believe to be helpful for software managers to make informed decisions. In this study we explored the costs of the new approach by tracking the technical debt management activities in an on-going software project. The results from the study provided insights into the impact of technical debt management on software projects. In particular, we found that there is a significant start-up cost when beginning to track and monitor technical debt, but the cost of ongoing management soon declines to very reasonable levels.
---
paper_title: Technical Debt Management with Genetic Algorithms

paper_content:

Management of technical debt is a challenging andpoorly understood task, and it is becoming even harder inthe case of modern software engineering practices like Agiledevelopment and Continuous Delivery. In this research we assume an agile software development and management process where the organization selects the tasks in the beginning of each sprint. The candidate tasks include implementation of new features with assumed business value and paying back technical debt. The organization needs to select a combination of tasks thatis implementable by the available resources and maximize thebenefit for the organization. The required optimization problemin a large project is complex and is also a multi-objective problem, which involves trade-off between short-term and long-term valuedelivered by the software. In this paper, we apply a multiobjectivegenetic algorithm for solving such an optimizationproblem. The potential of the algorithm is demonstrated byapplying it to a student project.
---
paper_title: How do software development teams manage technical debt? - An empirical study

paper_content:

Exploratory case study with empirical data from eight software development teams.Observation of various different strategies for technical debt management.Developed technical debt management framework. Technical debt (TD) is a metaphor for taking shortcuts or workarounds in technical decisions to gain short-term benefit in time-to-market and earlier software release. In this study, one large software development organization is investigated to gather empirical evidence related to the concept of technical debt management (TDM). We used the exploratory case study method to collect and analyze empirical data in the case organization by interviewing a total of 25 persons in eight software development teams. We were able to identify teams where the current strategy for TDM was only to fix TD when necessary, when it started to cause too much trouble for development. We also identified teams where the management had a systematic strategy to identify, measure and monitor TD during the development process. It seems that TDM can be associated with a similar maturity concept as software development in general. Development teams may raise their maturity by increasing their awareness and applying more advanced processes, techniques and tools in TDM. TDM is an essential part of sustainable software development, and companies have to find right approaches to deal with TD to produce healthy software that can be developed and maintained in the future.
---
paper_title: Revealing Social Debt with the CAFFEA Framework: An Antidote to Architectural Debt

paper_content:

Large software companies need a well-managed Software Architecture to support continuous and fast delivery of customer value both in the short and long term. However, this can be hindered if both evolution and maintenance of existing systems are hampered by Architectural Technical Debt. To avoid the accumulation and the costly consequences of ATD, it is critical that the responsibilities to minimize it are well understood and shared in a large software organization. In this paper, we argue that an organizational model, based on a well validated framework such as CAFFEA, can be used to reveal sub-optimalities in the social structure of the organization: in other words, it can reveal Social Debt. Such sub-optimality, according to previous work, leads to the accumulation of ATD. In conclusion, using the CAFFEA framework as an organizational analysis tool, can reveal weak spots (Social Debt) in the organization and can help preventing costly ATD and its consequences.
---
paper_title: JSpIRIT: a flexible tool for the analysis of code smells

paper_content:

Code smells are a popular mechanism to identify structural design problems in software systems. Since it is generally not feasible to f x all the smells arising in the code, some of them are often postponed by developer s to be resolved in the future. One reason for this decision is that the improvement of the code structure, to achieve modifability goals, requires extra effort from developer s. Therefore, they might not always spend this additional effort, particularly when they are focused on delivering customer-visible features. This postponement of code smells are seen as a source of technical debt. Furthermore, not all the code smells may be urgent to f x in the context of the system's modifability and business goals. While there are a number of tools to detect smells, they do not allow developer s to discover the most urgent smells according to their goals. In this article, we present a fexible tool to prioritize technical debt in the form of code smells. The tool is fexible to allow developer s to add new smell detection strategies and to prioritize smells, and groups of smells, based on the confguration of their manifold criteria. To illustrate this fexibility, we present an application example of our tool. The results suggest that our tool can be easily extended to be aligned with the developer's goals.
---
paper_title: A heuristic for estimating the impact of lingering defects: can debt analogy be used as a metric?

paper_content:

Background: Due to tight scheduling and limited budget, it may not be possible to resolve all the existing bugs in a current release of a software product. The accumulation of the deferred bugs in the issue tracking system are obligations (liabilities) of the software team similar to financial analogy of 'debt'. Defect debt is known as latent defects which are not resolved in the current release. Aim: In order to manage the defect debt, software managers need to be aware of the amount of debt (principal) as well as the price of the credit (interest) in their system. There are no studies in the literature to measure the principal or interest of defect debt. In this study, we propose a novel approach to identify the interest of defect debt. Methodology: We developed a heuristic to specify the interest based on three metrics: PageRank index, customer feedback and bug fixing duration. In order to investigate the feasibility of our heuristic, we employ it to two datasets that are extracted from both open source and commercial software products. We validate the heuristic using two metrics: the severity/priority of bugs, and the duration of bug fixing time. Result: The results show that 24% and 18% of the deferred bugs are high and medium impact bugs in project 1 and project 2, respectively.
---
paper_title: On the use of time series and search based software engineering for refactoring recommendation

paper_content:

To improve the quality of software systems, one of the widely used techniques is refactoring, defined as the process of improving the design of an existing system by changing its internal structure without altering the external behavior. The majority of existing refactoring works do not consider the impact of recommended refactorings on the quality of future releases of a system. In this paper, we propose to combine the use of search-based software engineering with time series to recommend good refactoring strategies in order to manage technical debt. We used a multi-objective algorithm to generate refactoring solutions that maximize the correction of important quality issues and minimize the effort. For these two fitness functions, we adapted time series forecasting to estimate the impact of the generated refactorings solution on future next releases of the system by predicting the evolution of the remaining code smells in the system, after refactoring, using different quality metrics. We evaluated our approach on one industrial project and a benchmark of 4 open source systems. The results confirm the efficiency of our technique to provide better refactoring management comparing to several existing refactoring techniques.
---
paper_title: Assessing code smell interest probability: a case study

paper_content:

An important parameter in deciding to eliminate technical debt (TD) is the probability of a module to generate interest along software evolution. In this study, we explore code smells, which according to practitioners are the most commonly occurring type of TD in industry, by assessing the associated interest probability. As a proxy of smell interest probability we use the frequency of smell occurrences and the change proneness of the modules in which they are identified. To achieve this goal we present a case study on 47,751 methods extracted from two well-known open source projects. The results of the case study suggest that: (a) modules in which "code smells" are concentrated are more change-prone than smell-free modules, (b) there are specific types of "code smells" that are concentrated in the most change-prone modules, and (c) interest probability of code clones seems to be higher than the other two examined code smells. These results can be useful for both researchers and practitioners, in the sense that the former can focus their research on resolving "code smells" that produce more interest, and the latter can improve accordingly the prioritization of their repayment strategy and their training.
---
paper_title: Revealing Social Debt with the CAFFEA Framework: An Antidote to Architectural Debt

paper_content:

Large software companies need a well-managed Software Architecture to support continuous and fast delivery of customer value both in the short and long term. However, this can be hindered if both evolution and maintenance of existing systems are hampered by Architectural Technical Debt. To avoid the accumulation and the costly consequences of ATD, it is critical that the responsibilities to minimize it are well understood and shared in a large software organization. In this paper, we argue that an organizational model, based on a well validated framework such as CAFFEA, can be used to reveal sub-optimalities in the social structure of the organization: in other words, it can reveal Social Debt. Such sub-optimality, according to previous work, leads to the accumulation of ATD. In conclusion, using the CAFFEA framework as an organizational analysis tool, can reveal weak spots (Social Debt) in the organization and can help preventing costly ATD and its consequences.
---
paper_title: Exploring the costs of technical debt management – a case study

paper_content:

Technical debt is a metaphor for delayed software maintenance tasks. Incurring technical debt may bring short-term benefits to a project, but such benefits are often achieved at the cost of extra work in future, analogous to paying interest on the debt. Currently technical debt is managed implicitly, if at all. However, on large systems, it is too easy to lose track of delayed tasks or to misunderstand their impact. Therefore, we have proposed a new approach to managing technical debt, which we believe to be helpful for software managers to make informed decisions. In this study we explored the costs of the new approach by tracking the technical debt management activities in an on-going software project. The results from the study provided insights into the impact of technical debt management on software projects. In particular, we found that there is a significant start-up cost when beginning to track and monitor technical debt, but the cost of ongoing management soon declines to very reasonable levels.
---
paper_title: A heuristic for estimating the impact of lingering defects: can debt analogy be used as a metric?

paper_content:

Background: Due to tight scheduling and limited budget, it may not be possible to resolve all the existing bugs in a current release of a software product. The accumulation of the deferred bugs in the issue tracking system are obligations (liabilities) of the software team similar to financial analogy of 'debt'. Defect debt is known as latent defects which are not resolved in the current release. Aim: In order to manage the defect debt, software managers need to be aware of the amount of debt (principal) as well as the price of the credit (interest) in their system. There are no studies in the literature to measure the principal or interest of defect debt. In this study, we propose a novel approach to identify the interest of defect debt. Methodology: We developed a heuristic to specify the interest based on three metrics: PageRank index, customer feedback and bug fixing duration. In order to investigate the feasibility of our heuristic, we employ it to two datasets that are extracted from both open source and commercial software products. We validate the heuristic using two metrics: the severity/priority of bugs, and the duration of bug fixing time. Result: The results show that 24% and 18% of the deferred bugs are high and medium impact bugs in project 1 and project 2, respectively.
---
paper_title: The Pricey Bill of Technical Debt: When and by Whom will it be Paid?

paper_content:

Software companies need to support continuous and fast delivery of customer value both in short and a long-term perspective. However, this can be hindered by evolution limitations and high maintenance efforts due to internal software quality issues by what is described as Technical Debt. Although significant theoretical work has been undertaken to describe the negative effects of Technical Debt, these studies tend to have a weak empirical basis and often lack quantitative data. The aim of this study is to estimate wasted time, caused by the Technical Debt interest during the software life-cycle. This study also investigates how practitioners perceive and estimate the impact of the negative consequences due to Technical Debt during the software development process. This paper reports the results of both an online web-survey provided quantitative data from 258 participants and follow-up interviews with 32 industrial software practitioners. The importance and originality of this study contributes and provides novel insights into the research on Technical Debt by quantifying the perceived interest and the negative effects it has on the software development life-cycle. The findings show that on average, 36% of all development time is estimated to be wasted due to Technical Debt; Complex Architectural Design and Requirement Technical Debt generates most negative effect; and that most time is wasted on understanding and/or measuring the Technical Debt. Moreover, the analysis of the professional roles and the age of the software system in the survey revealed that different roles are affected differently and that the consequences of Technical Debt are also influenced by the age of the software system.
---
paper_title: An empirically developed method to aid decisions on architectural technical debt refactoring: AnaConDebt

paper_content:

Architectural Technical Debt is regarded as sub-optimal architectural solutions that need to be refactored in order to avoid the payment of a costly interest in the future. However, decisions on if and when to refactor architecture are extremely important and difficult to take, since changing software at the architectural level is quite expensive. Therefore it is important, for software organizations, to have methods and tools that aid architects and managers to understand if Architecture Technical Debt will generate a costly and growing interest to be paid or not. Current knowledge, especially empirically developed and evaluated, is quite scarce. In this paper we developed and evaluated a method, AnaConDebt, by analyzing, together with several practitioners, 12 existing cases of Architecture Debt in 6 companies. The method has been refined several times in order to be useful and effective in practice. We also report the evaluation of the method with a final case, for which we present anonymized results and subsequent refactoring decisions. The method consists of several components that need to be analyzed, combining the theoretical Technical Debt framework and the practical experience of the practitioners, in order to identify the key factors involved in the growth of interest. The output of the method shows summarized indicators that visualizes the factors in a useful way for the stakeholders. This analysis aids the practitioners in deciding on if and when to refactor Architectural Technical Debt items. The method has been evaluated and has been proven useful to support the architects into systematically analyze and decide upon a case.
---
paper_title: Anacondebt: a tool to assess and track technical debt

paper_content:

It is challenging to assess and manage Technical Debt. Technical Debt is avoided or refactored if the long-term benefits, such as preventing extra-costs, exceed the cost of repaying the debt. Some tools have been recently proposed for the identification of Technical Debt, but most of them do not help in assessing the cost-benefits of repaying the Debt. Besides, it is challenging to track, visualize and plan Technical Debt refactoring systematically. Although practitioners might use simple tracking tools, calculating and communicating Technical Debt is currently not supported. Based on the results of previous research, combined with several practical experiences in collaboration with large software companies, we have developed and evaluated a lightweight tool, AnaConDebt, to track and assess Technical Debt.
---
paper_title: A Strategy Based on Multiple Decision Criteria to Support Technical Debt Management

paper_content:

Technical debt (TD) refers to likely long-term costs associated with software development shortcuts taken by programmers to achieve short-term business benefits. If a development team does not manage TD, it can cause significant long-term problems such as high maintenance costs. Management strategies monitor debt items and evaluate when and if they should be paid. In order to effectively support this task, the systematic use of decision criteria can be decisive. In this context, this paper presents a strategy for TD management that uses multiple decision criteria to decide when to pay debt items off. In addition, it presents a case study that assessed the feasibility of the proposed strategy regarding its usefulness, ease of use and self-predicted future use. The results provided positive evidence on the use of the proposed strategy, indicating (i) that it can be useful in supporting TD management activities and (ii) that it can bring gains in terms of productivity, performance, and efficacy when evaluating the desirable time to pay debt items off.
---
paper_title: Arcan: A Tool for Architectural Smells Detection

paper_content:

Code smells are sub-optimal coding circumstances such as blob classes or spaghetti code - they have received much attention and tooling in recent software engineering research. Higher-up in the abstraction level, architectural smells are problems or sub-optimal architectural patterns or other design-level characteristics. These have received significantly less attention even though they are usually considered more critical than code smells, and harder to detect, remove, and refactor. This paper describes an open-source tool called Arcan developed for the detection of architectural smells through an evaluation of several different architecture dependency issues. The detection techniques inside Arcan exploit graph database technology, allowing for high scalability in smells detection and better management of large amounts of dependencies of multiple kinds. In the scope of this paper, we focus on the evaluation of Arcan results carried out with real-life software developers to check if the architectural smells detected by Arcan are really perceived as problems and to get an overall usefulness evaluation of the tool.
---
paper_title: Automatic Detection of Instability Architectural Smells

paper_content:

Code smells represent well known symptoms of problems at code level, and architectural smells can be seen as their counterpart at architecture level. If identified in a system, they are usually considered more critical than code smells, for their effect on maintainability issues. In this paper, we introduce a tool for the detection of architectural smells that could have an impact on the stability of a system. The detection techniques are based on the analysis of dependency graphs extracted from compiled Java projects and stored in a graph database. The results combine the information gathered from dependency and instability metrics to identify flaws hidden in the software architecture. We also propose some filters trying to avoid possible false positives.
---
paper_title: Identifying and Prioritizing Architectural Debt Through Architectural Smells: A Case Study in a Large Software Company

paper_content:

Architectural technical debt can have a huge impact on software maintainability and evolution. Hence, different architectural violations, detected as architectural smells, need to be identified and refactored. In this paper, we conducted a multiple case-study on several architectural smells detected in four industrial projects. We conducted an in-depth investigation with a questionnaire, interviews and thorough inspection of the code with the practitioners. We evaluated the negative impact of the technical debt detected by the architectural smells, their difficulty to be refactored and the usefulness of the detection tool. The results show that practitioners appreciated the help of automatic detection, and that they prioritize refactoring architectural debt that causes more negative impact despite the higher refactoring effort.
---
paper_title: A formal approach to technical debt decision making

paper_content:

The notion of technical debt attracts significant attention, especially in the context of reconciling architecture and agile development. However, most work on technical debt is still largely informal and if it provides a formalization it is often ad-hoc. In this paper, we provide a detailed, formal analysis of decision making on technical debt in development. Using this formalization, we show that optimal decision making is not effectively computable in real-world situations and provide several well-defined approximations that allow to handle the problem nevertheless in practical situations. Combining these approximations in a single method leads to a light-weight approach that can be effectively applied in iterative software development, including agile approaches.
---
paper_title: Technical debt cripples software developer productivity: a longitudinal study on developers' daily software development work

paper_content:

Software companies need to continuously deliver customer value, both from a short- and long-term perspective. However, software development can be impeded by what has been described as Technical Debt (TD). The aim of this study is to explore the negative consequences of TD in terms of wasted software development time. This study also investigates on which additional activities this wasted time is spent and whether different types of TD impact the wasted time differently. This study also sets out to examine the benefits of tracking and communicating the amount of wasted time, both from a developer's and manager's perspective. This paper reports the results of a longitudinal study, surveying 43 software developers, together with follow-up interviews with 16 industrial software practitioners. The analysis of the reported wasted time revealed that developers waste, on average, 23% of their development time due to TD and that they are frequently forced to introduce new TD due to already existing TD. The most common activity on which additional time is spent is performing additional testing.
---
paper_title: A Multiple Case Study of Continuous Architecting in Large Agile Companies: Current Gaps and the CAFFEA Framework

paper_content:

In order to continuously support the value delivery both in short-term and long-term, a key goal for large software companies is to continuously develop and manage software architecture. In order to understand how architecture management is employed in large Agile software companies, we have conducted interviews involving several roles at 5 firms. Through a combination of structured inductive and deductive analysis proper of Grounded Theory, we have identified current architect roles and gaps in the architecture practices in the studied organizations. From such investigation, we have developed an organizational framework, CAFFEA, for Agile architecting, including roles, (virtual) teams and practices. The framework has been evaluated through a cross-company workshop including participants from 5 large software companies, discussion groups and a final survey. Finally, we have evaluated the framework in practice after one year of its application at one of the companies. We found that some necessary architectural practices are overlooked in Large Agile Software Development. The evaluation of CAFFEA framework showed that the included roles and teams are needed in order to mitigate the gaps in the architectural practices. The responsibilities and the activities have been mapped to key architect roles compatible with the Scrum setting employed at the companies. The evaluation of CAFFEA shows key benefits.
---
paper_title: Managing architectural technical debt: A unified model and systematic literature review

paper_content:

Large Software Companies need to support the continuous and fast delivery of customer value in both the short and long term. However, this can be impeded if the evolution and maintenance of existing systems is hampered by what has been recently termed Technical Debt (TD). Specifically, Architectural TD has received increased attention in the last few years due to its significant impact on system success and, left unchecked, it can cause expensive repercussions. It is therefore important to understand the underlying factors of architectural TD. With this as background, there is a need for a descriptive model to illustrate and explain different architectural TD issues. The aim of this study is to synthesize and compile research efforts with the goal of creating new knowledge with a specific interest in the architectural TD field. The contribution of this paper is the presentation of a novel descriptive model, providing a comprehensive interpretation of the architectural TD phenomenon. This model categorizes the main characteristics of architectural TD and reveals their relations. The results show that, by using this model, different stakeholders could increase the system's success rate, and lower the rate of negative consequences, by raising awareness about architectural TD.
---
paper_title: Estimating the breaking point for technical debt

paper_content:

In classic economics, when borrowing an amount of money that causes a debt to the issuer, it is not usual to have interest which can become larger than the principal. In the context of technical debt however, accumulated debt in the form of interest can in some cases quickly sum up to an amount that at some point, becomes larger than the effort required to repay the initial amount of technical debt. In this paper we propose an approach for estimating this breaking point. Anticipating how late the breaking point is expected to come can support decision making with respect to investments on improving quality. The approach is based on a search-based optimization tool that is capable of identifying the distance of an actual object-oriented design to the corresponding optimum one.
---
paper_title: A Strategy Based on Multiple Decision Criteria to Support Technical Debt Management

paper_content:

Technical debt (TD) refers to likely long-term costs associated with software development shortcuts taken by programmers to achieve short-term business benefits. If a development team does not manage TD, it can cause significant long-term problems such as high maintenance costs. Management strategies monitor debt items and evaluate when and if they should be paid. In order to effectively support this task, the systematic use of decision criteria can be decisive. In this context, this paper presents a strategy for TD management that uses multiple decision criteria to decide when to pay debt items off. In addition, it presents a case study that assessed the feasibility of the proposed strategy regarding its usefulness, ease of use and self-predicted future use. The results provided positive evidence on the use of the proposed strategy, indicating (i) that it can be useful in supporting TD management activities and (ii) that it can bring gains in terms of productivity, performance, and efficacy when evaluating the desirable time to pay debt items off.
---
paper_title: The magnificent seven: towards a systematic estimation of technical debt interest

paper_content:

The interest of Technical Debt is difficult to assess. The negative effects (severity) of Technical Debt might depend on the context of the organization and the estimations might be subjective. There is a need for assessing Technical Debt interest in a more systematic way. Based on the results of previous research, we have developed and used a lightweight tool, AnaConDebt, to assess the severity of the interest of 9 Technical Debt items with the stakeholders in 3 Agile teams. The systematic and semi-automatic assessment of seven factors and their growth has been compared to the stakeholders' intuitive estimations. The results show that the outcome of the tool is very close to the estimation given by the stakeholders. The implications are that, if further data support the hypothesis, the severity of the interest can be systematically assessed by the stakeholders by estimating only seven factors in a cost-effective manner with acceptable results.
---
paper_title: A systematic mapping study on technical debt and its management

paper_content:

A systematic mapping study on technical debt and its management.Ninety-four papers are finally selected for data extraction and analysis.Technical debt was classified into 10 types.Eight activities of and 29 tools for technical debt management were identified.Code-related technical debt has gained the most attention. ContextTechnical debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefit but may hurt the long-term health of a software system. ObjectiveThis work aims at collecting studies on TD and TD management (TDM), and making a classification and thematic analysis on these studies, to obtain a comprehensive understanding on the TD concept and an overview on the current state of research on TDM. MethodA systematic mapping study was performed to identify and analyze research on TD and its management, covering publications between 1992 and 2013. ResultsNinety-four studies were finally selected. TD was classified into 10 types, 8 TDM activities were identified, and 29 tools for TDM were collected. ConclusionsThe term "debt" has been used in different ways by different people, which leads to ambiguous interpretation of the term. Code-related TD and its management have gained the most attention. There is a need for more empirical studies with high-quality evidence on the whole TDM process and on the application of specific TDM approaches in industrial settings. Moreover, dedicated TDM tools are needed for managing various types of TD in the whole TDM process.
---
paper_title: A Multiple Case Study of Continuous Architecting in Large Agile Companies: Current Gaps and the CAFFEA Framework

paper_content:

In order to continuously support the value delivery both in short-term and long-term, a key goal for large software companies is to continuously develop and manage software architecture. In order to understand how architecture management is employed in large Agile software companies, we have conducted interviews involving several roles at 5 firms. Through a combination of structured inductive and deductive analysis proper of Grounded Theory, we have identified current architect roles and gaps in the architecture practices in the studied organizations. From such investigation, we have developed an organizational framework, CAFFEA, for Agile architecting, including roles, (virtual) teams and practices. The framework has been evaluated through a cross-company workshop including participants from 5 large software companies, discussion groups and a final survey. Finally, we have evaluated the framework in practice after one year of its application at one of the companies. We found that some necessary architectural practices are overlooked in Large Agile Software Development. The evaluation of CAFFEA framework showed that the included roles and teams are needed in order to mitigate the gaps in the architectural practices. The responsibilities and the activities have been mapped to key architect roles compatible with the Scrum setting employed at the companies. The evaluation of CAFFEA shows key benefits.
---
paper_title: Empirical studies of agile software development : A systematic review

paper_content:

Agile software development represents a major departure from traditional, plan-based approaches to software engineering. A systematic review of empirical studies of agile software development up to and including 2005 was conducted. The search strategy identified 1996 studies, of which 36 were identified as empirical studies. The studies were grouped into four themes: introduction and adoption, human and social factors, perceptions on agile methods, and comparative studies. The review investigates what is currently known about the benefits and limitations of, and the strength of evidence for, agile methods. Implications for research and practice are presented. The main implication for research is a need for more and better empirical studies of agile software development within a common research agenda. For the industrial readership, the review provides a map of findings, according to topic, that can be compared for relevance to their own settings and situations.
---
paper_title: Guidelines for snowballing in systematic literature studies and a replication in software engineering

paper_content:

Background: Systematic literature studies have become common in software engineering, and hence it is important to understand how to conduct them efficiently and reliably. Objective: This paper presents guidelines for conducting literature reviews using a snowballing approach, and they are illustrated and evaluated by replicating a published systematic literature review. Method: The guidelines are based on the experience from conducting several systematic literature reviews and experimenting with different approaches. Results: The guidelines for using snowballing as a way to search for relevant literature was successfully applied to a systematic literature review. Conclusions: It is concluded that using snowballing, as a first search strategy, may very well be a good alternative to the use of database searches.
---

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

Section 1: Introduction
Description 1: Provide an overview of technical debt, its implications, and the need for prioritization. Explain the motivation and goal of this systematic literature review.

Section 2: Background
Description 2: Define technical debt and its types, elaborate on the concept, and summarize previous systematic literature reviews on the topic.

Section 3: Technical Debt
Description 3: Discuss the evolution of the technical debt concept, definitions by different researchers, and classifications of technical debt types.

Section 4: Previous SLR's
Description 4: Summarize prior systematic reviews related to technical debt, their methods, findings, and gaps.

Section 5: Technical Debt Prioritization
Description 5: Explain the methodology used in this systematic literature review, including the goal, research questions, search strategy, quality assessment, and data extraction.

Section 6: Goal and Research Questions
Description 6: Present the study's goals and the formulated research questions aimed at investigating how technical debt is prioritized in software organizations.

Section 7: Search Strategy
Description 7: Describe the search strategy, including bibliographic sources, search terms, inclusion and exclusion criteria, and the selection process.

Section 8: Quality Assessing
Description 8: Explain the quality assessment process and criteria used to evaluate the selected papers.

Section 9: Data Extraction
Description 9: Detail the data extraction process, including context, process, and outcome data collected from primary studies.

Section 10: Overview of the Primary Studies
Description 10: Provide an overview of the identified primary studies, their focus, and distribution over years.

Section 11: Results
Description 11: Present the results for each research question, including the types of technical debt investigated, prioritization approaches, and measures used.

Section 12: Discussion
Description 12: Discuss the implications of the results for researchers and practitioners, highlight the main findings, and identify areas for future research.

Section 13: Threats to Validity
Description 13: Address potential threats to the validity of the review, including construct, internal, external, and conclusion validity threats.

Section 14: Conclusion
Description 14: Summarize the key findings of the review, its contributions to the field, and suggest future work to advance the understanding and management of technical debt prioritization.