Context . Technical debt (TD) prevention allows software practitioners to apply practices to avoid potential TD items in their projects. Aims . To uncover and prioritize, from the point of view of software practitioners, the practices that could be used to avoid TD items, the relations between these practices and the causes of TD, and the practice avoidance reasons (PARs) that could explain the failure to prevent TD. Method . We analyze data collected from six replications of a global industrial family of surveys on TD, totaling 653 answers. We also conducted a follow up survey to understand the importance level of analyzed data. Results . Most practitioners indicated that TD could be prevented, revealing 89 prevention practices and 23 PARs for explaining the failure to prevent TD. The article identifies statistically significant relationships between preventive practices and certain causes of TD. Further, it prioritizes the list of practices, PARs, and relationships regarding their level of importance for TD prevention based on the opinion of software practitioners. Conclusion . This work organizes TD prevention practices and PARs in a conceptual map and the relationships between practices and causes of TD in a Sankey diagram to help the visualization of the body of knowledge reported in this study.

Context: Knowing the effects of technical debt (TD) can support software development teams in the prioritization of TD items to pay off. However, little is known about the relations between the effects of TD and TD payment practices. Having this knowledge can provide valuable information for decision making about which payment practice can be applied given the presence of specific effects of TD. Aims: To investigate, from the point of view of software practitioners, (i) which TD payment practices have been used when certain effects of the presence of debt are felt in software projects and (ii) the reasons for not paying debt items despite the effects they are causing to the project. Method: We analyze quantitatively and qualitatively data collected from a survey with 432 practitioners across four countries. Results: Among the identified relations, the practice "code refactoring" is commonly used to pay debt items off when the effects "delivery delay" and "rework" are felt in software projects. On the other hand, when practitioners face the TD effects "low external quality" and "delivery delay", ，they commonly justify the non- payment of the debt items indicating the need of "focusing on short term goals". Conclusion: We organize the relationship between TD effects, and payment practices and reasons for not eliminating debt items. All this information is structured in an alluvial diagram, which can facilitate the visualization of the identified relations.

Background: Little is known about the practices used for technical debt (TD) payment. The study of payment practices, as well as the reasons for not applying them, can help practitioners to control and manage TD items. Aims: To investigate, from the point of view of software practitioners, if TD items have been paid off in software projects, the practices that have been used to pay off TD and the reasons that hamper the implementation of these practices. Method: We analyzed - both quantitatively and qualitatively - a corpus of responses from a survey of 432 practitioners, from four countries, about the possibility of TD payment. Results: We found that, for most of the cases, TD items have not been eliminated from software projects. The main reasons for not paying off TD are lack of organizational interest, low priority on the debt, focus on short-term goals, cost, and lack of time. On the other hand, we identified that code refactoring, design refactoring, and update system documentation are the most used practices for TD payment. Practitioners also cited practices related to the prevention, prioritization, and creation of a favorable setting as part of TD payment initiatives. Conclusion: This paper summarizes the identified practices and reasons for not paying off debt items in a map. Our map reveals that the majority of payment practices are of a technical nature while the majority of reasons for not paying off debts are associated with non-technical issues.

Background: The concept of technical debt (TD) describes a phenomenon that impacts software projects and makes them difficult to manage. In recent years, various techniques and best practices in terms of TD management were proposed and although important on its own this knowledge must be complemented with a broader comprehension of what causes TD and what are the effects of TD. This paper presents a replication of the InsighTD survey-a globally distributed family of industrial surveys on causes and effects of TD-and thus amplifies the InsighTD reach and expands its knowledge base. Objective: The research presented in this paper gives insight on the state of practice and understanding of the TD concept alongside with data on causes and effects of TD in the Serbian IT industry. Method: A nation-wide survey, as a part of the InsighTD initiative, was conducted in Serbia in order to obtain feedback from software industry practitioners. Results: In total 93 practitioners from the Serbian IT industry filled out the survey. The results indicate that the concept of TD is broadly distributed, but at the same time it is not widely accepted for use (only 35% of participants had some sort of practical experiences with projects that were TD aware). The top cited causes were: deadlines, ineffective project management, lack of experience, test not performed and misconduct. On the other side the most common effects of TD were: low maintainability, increased effort, rework and low external quality. Conclusion: The research presented in this paper confirms the original study findings that deadlines are the top cited cause of TD. It also identifies new causes of TD in the context of InsighTD, with misconduct being one of the most cited ones. Regarding the effects of TD this research differs in most of the top 10 identified effects from the original study but confirms the occurrence of some effects most cited.

Context: Technical debt (TD) is a metaphor used to describe technical decisions that can give the company a benefit in the short term but possibly hurting the overall quality of the software in the long term. Objective: This study aims to characterize the current state of practices related to TD payment from the point of view of software practitioners. Method: We used a survey research method to collect and analyze - both quantitatively and qualitatively - a corpus of responses from a survey of 432 software practitioners from Colombia, Chile, Brazil, and the United States, as a part of the InsighTD project. Results: We were able to identify that refactoring (24.3%) was the main practice related to TD payment, along with improving testing (6.2%) and improve design (5.8%). Also, we identify that small-sized systems and big-sized systems, along with young systems (less than one year) tend to use more refactoring. As a part of these results, we also could identify that some practices do not eliminate the debt by itself, but support a favorable scenario for TD payment or prevention. Additionally, after comparing the three major TD types cited (code debt, test debt and design debt) we could discover an important similarity of TD payment practices between code debt and design debt. Lastly, we identified that no matter the cause leading to TD occurrence, refactoring remained the most common practice. Conclusion: Definition of practices related to TD payment is an essential activity for software development teams. Developing healthy software systems that can be maintained in the future requires that companies find the right approaches for TD payment.

Understanding TD causes can support development teams in defining actions that could be taken to prevent the occurrence of debt items. Understanding the effects of TD could aid in prioritization of TD items to pay off to minimize possible negative consequences for the project. Existing work has revealed 105 causes and 85 effects of TD, and this high number can make it difficult to make practical use of this information. Without a consolidated representation, we would need to rely on a set of tables and isolated pieces of data. In this work, we propose the use of cross-company probabilistic cause-effect diagrams to represent information about TD causes and effects. We hypothesize that such diagrams can be useful to support TD cause/effect analysis sessions and empirically investigate this issue. Results from a case study performed with 72 participants indicate that the diagrams are able to positively support the management of TD, making it easier to identify its causes and the effects of its presence. Most of the participants also agreed that, by using the proposed diagrams, they gain agility, productivity, performance, and effectiveness. Finally, 89% of the participants stated that the use of the diagrams helped them to identify causes and effects of TD that they would not have identified without their support.

Background: The presence of technical debt (TD) brings risks to a software project and makes it difficult to manage. Several TD management strategies have been proposed, but considering actions that could explicitly prevent the insertion of TD in the first place and monitor its effects is not yet a common practice. Thus, while TD management is an important topic, it is also worthwhile to understand the causes that could lead development teams to incur different types of debt as well as the effects of their presence on software projects. Aims: The objective of this work is twofold. First, we investigate the state of practice in the TD area including the status quo, the causes that lead to TD occurrence, and the effects of existing TD. Second, we present the design of InsighTD, a globally distributed family of industrial surveys on causes and effects of TD, and the results of its first execution. Method: We designed the InsighTD in joint collaboration with several TD researchers. It is designed to run as an incremental large scale study based on continuous and independent replications of the questionnaire in different countries. Results: This paper presents the first results of the first execution of the survey. In total, 107 practitioners from the Brazilian software industry answered the questionnaire. Results indicate that there is a broad familiarity with the concept of TD. Deadlines, inappropriate planning, lack of knowledge, and lack of a well-defined process are among the top 10 cited and most likely causes that lead to the occurrence of TD. On the other side, low quality, delivery delay, low maintainability, rework and financial loss are among the top 10 most commonly cited and impactful effects of TD. Conclusion: With InsighTD, we intend to reduce the problem of isolated investigations in TD that are not yet representative and, thus, build a continuous and generalizable empirical basis for understanding practical problems and challenges of TD.

Context: Several technical debt (TD) management strategies have been proposed, but considering actions that could prevent the insertion of TD in the first place is not yet a common practice. This is a point that deserves investigation because it is expected that TD prevention could be sometimes "cheaper" than TD repayment. Besides, TD prevention also helps other TD management activities, especially in catching inexperienced developers' 'not-so-good' solutions. Thus, while TD management is an important topic, it is also worthwhile to understand the motivations and factors that could lead development teams to incur different types of debt. Objective: To identify causes that lead to the occurrence of TD, investigate if these causes occur in isolation or in combination, understand if TD can be prevented, and investigate, in terms of effort, if it is better to prevent debt, or incur it and pay it off later. Method: An interview based case study was performed with software practitioners. The results were formulated based on a synthesis of the text fragments coded for each response. Results: We identified 57 causes that lead a development team to incur debt. For the majority of TD types, these causes occur in combination. It was also indicated that debt can be prevented, and it is better to work on prevention activities than to pay off debt later. Conclusion: Results allowed us to identify 57 causes that lead a development team to incur debt. These causes mostly occur in combination, not in isolation. It was also indicated that debt can be prevented, and it would be better to work on prevention activities than to pay off debt later.

The current scenario of software development is characterized by a wide adoption of agile methodologies, which define processes and practices that address a range of problems faced by development teams.However, there is still little information on how these methodologies deal with technical debt(TD).This work presents the results of a replicated survey(originally executed in Finland) whose goal was to investigate which agile practices and processes are sensitive to TD.Despite this replication allows different types of analysis, the focus of this paper will be on the analysis of the effects of the agile practices and processes on TD from the perspective of the Brazilian software industry, where the study was replicated.At total, 62 practitioners from different organizations answered the questionnaire.The results indicated that participants already had a good knowledge about TD, instances of TD reside in the software implementation and are caused due to deficiencies in its architecture, the size of a debt item is proportional to its impact on the project, and, refactoring and iteration have the most positive effect on TD.This replication also contributes to the investigated topic through the accumulation of evidence about the findings, thereby increasing the level of confidence in results.

Context] The software engineering community considers the technical debt (TD) concept intuitive, because it facilitates discussion among team members about problems that can impact the software development.Personal opinions and experiences related to the concept have been published in blogs and other channels without any evaluation, originating the TD Folklore.[Goal] This work aims to investigate TD Folklore statements classifying them by agreement and consensus.Besides, we also investigated if software development experience affects the perception of developers.[Method] We replicated a survey to evaluate TD Folklore statements.In the replication, we increased the number of respondents and added a new research question to analyze the difference of opinions between participants with and without software experience.[Results] At total, the survey was answered by 107 respondents.The list of TD Folklore was reorganized by the ranking of agreement and consensus indicated by participants.We also identified that professional experience does not change the participants´ perception on the concept of TD for the most cases.[Conclusion] We believe that TD Folklore can help researchers and practitioners identify gaps for new research efforts.

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.