No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
A Comprehensive View on TD Prevention Practices and Reasons for Not Preventing It
Abstract
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 paper 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.
... The studies are organized considering their published year. Concerning the TD management focus, Freire et al. (2020b) and Freire et al. (2024b) analyzed InsighTD data sets to understand TD prevention in the software industry, revealing a list of preventive actions used by software practitioners for avoiding TD items and the impediments faced by practitioners that hamper the application of those actions. Pérez et al. (2021) investigated the repayment and prevention practices used by software architects by analyzing 72 answers collected by Brazilian, Chilean, Colombian, and North American InsighTD replication teams in their respective software industries. ...
Context. Technical debt (TD) monitoring allows software professionals to track the evolution of debt incurred in their projects. The technical literature has listed several practices used in the software industry to monitor indebtedness. However, there is limited evidence on the use and on the reasons to avoid using these practices. Aims. This work aims to investigate, from the point of view of software practitioners, the practices used for monitoring TD items, and the practice avoidance reasons (PARs) curbing the monitoring of TD items. Method. We analyze quantitatively and qualitatively a set of 653 answers collected with a family of industrial surveys distributed in six countries. Results. Practitioners are prone to monitor TD items, revealing 46 practices for monitoring the debt and 35 PARs for explaining TD non-monitoring. Both practices and PARs are strongly associated with planning and management issues. The study also shows the relationship found among practices, PARs and types of debt and presents a conceptual map that relates practices and PARs with their categories. Conclusion. The results of this study add to a practitioners’ capability to monitor TD items by revealing the monitoring practices, PARs and their relationship with different TD types.
Context: Agile methodologies use continuous delivery and adaptability to develop software that meets the needs of its users. However, such methods are prone to accumulate technical debt (TD). Agile teams must balance the benefits and risks of incurring debt by managing TD items. Knowing how TD management is conducted in agile software teams can help agile practitioners increase their ability to handle TD items.
Aims: To investigate, based on the state of the art, how agile software teams have managed existing TD items in their projects.
Method: We carried out a systematic mapping study covering 39 articles from 2010 to 2023.
Results: Among the agile methodologies, Scrum was the most used for TD management. Regarding practices, agile teams employ mostly user stories and sprint backlogs to identify TD items. Sprints and sprint backlogs are used to monitor debt, while refactoring is applied to prevent and repay TD items.
Conclusion: This study maps current knowledge on TD management in agile methodologies, serving as a starting point for new investigations in the area.
Context: The presence of technical debt (TD) brings risks to software projects. Managers must continuously find a cost-benefit balance between the benefits of incurring in TD and the costs of its presence in a software project. Much attention has been given to TD related to coding issues, but other types of debt can also have impactful consequences on projects. Aims: This paper seeks to elaborate on the growing need to expand TD research to other areas of software development, by analyzing six elements related to TD management, namely: causes, effects, preventive practices, reasons for non-prevention, repayment practices, and reasons for non-repayment of TD. Method: We survey and analyze, quantitatively and qualitatively, the answers of 653 software industry practitioners on TD to investigate how the previously mentioned elements are related to coding and non-coding issues of the software development process. Results: Coding issues are commonly related to the investigated elements but, indeed, they are only part of the TD Management stage. Issues related to the project planning and management, human factors, knowledge, quality, process, requirements, verification, validation, and test, design, architecture, and the organization are also common sources of TD. We organize the results in a hump diagram and specialize it considering the point of view of practitioners that have used agile, hybrid, and traditional process models in their projects. Conclusion: The hump diagram, in combination with the detailed results, provides guidance on what to expect from the presence of TD and how to react to it considering several issues of software development. The results shed light on TD management of software elements, beyond source code related artifacts.
Context: It is common for a software project to incur technical debt (TD) during its development. It can impact several artifacts produced throughout the software development process. Therefore, it is necessary to carry out management actions to find a balance between the benefits of incurring it and the effects of its presence. However, so far, much of the attention has been given only to discussions relating TD to coding issues. This is a worrying scenario because other types of debt can also have impactful, or even worse, consequences on projects. Aims: This study elaborates on the need to consider other issues of the development process and not just the source-code when investigating the TD phenomenon. Method: We analyze responses from 653 practitioners concerning TD causes, effects, prevention, reasons for non-prevention, repayment, and reasons for non-repayment and investigate whether these TD management elements are related to coding or to other software development issues. Results: Coding issues are commonly related to the investigated elements but, indeed, they are only part of the big picture we draw. Issues related to the project planning and management, human factors, knowledge, quality, process, requirements, verification, validation, and test, design, architecture, TD management, and the organization are also common. Lastly, we present a hump diagram that, in combination with the detailed results, provides guidance on what to expect from the presence of TD and how to react to it considering several issues of software development. Conclusion: The results shed light on other concerns beyond code that the research community and practitioners need to be aware of.
Context
The technical debt (TD) metaphor describes actions made during various stages of software development that lead to a more costly future regarding system maintenance and evolution. According to recent studies, on average 25% of development effort is spent, i.e. wasted, on TD caused issues in software development organizations. However, further research is needed to investigate the relations between various software development activities and TD.
Objective
The objective of this study is twofold. First, to get empirical insight on the understanding and the use of the TD concept in the IT industry. Second, to contribute towards precise conceptualization of the TD concept through analysis of causes and effects.
Method
In order to address the research objective a family of surveys was designed as a part of an international initiative that congregates researchers from 12 countries—InsighTD. At country level, national teams ran survey replications with industry practitioners from the respective countries.
Results
In total 653 valid responses were collected from 6 countries. Regarding the prevalence of the TD concept 22% of practitioners have only theoretical knowledge about it, and 47% have some practical experiences with TD identification or management. Further analysis indicated that senior practitioners who work in larger organizations, larger teams, and on larger systems are more likely to be experienced with TD management. Time pressure or deadlinewas the single most cited cause of TD. Regarding the effects of TD: delivery delay, low maintainability, and rework were the most cited.
Conclusion
InsighTD is the first family of surveys on technical debt in software engineering. It provided a methodological framework that allowed multiple replication teams to conduct research activities and to contribute to a single dataset. Future work will focus on more specific aspects of TD management.
As technical debt (TD) potentially occurs as a result of poor decisions that affect software development tasks, one might expect that practitioners following different process models, such as agile, hybrid or traditional, will perceive and manage the effects of TD differently. This study investigates the potential relationship between development process models and TD effects and their management by surveying 432 practitioners from software organizations in Brazil, Chile, Colombia, and the United States. Results indicate that, although opinions about debt prevention and repayment are the same regardless of the process model, there are differences in how practitioners monitor and feel the effects of TD. Development teams can use our findings to have a clearer view of the possible effects and managerial influence of TD in their projects for each type of process model.
When deadlines and resources of software projects become scarce, testing is usually in the first row to have its activities aborted or reduced; however, if defects cannot be found, product quality can be affected. In the software development process, aborted or reduced activities that can bring short-term benefits, but can be harmful to the project in the long run, are considered Technical Debt (TD) and, when the TDs impact testing activities, they are called Test Debt. Although there are several studies dealing with Test Debt, current solutions often deal with specific types of tests (e.g., exploratory and automated tests) and do not address the whole software testing process. Aiming to fill these gaps, this work then proposes a Test Debt Catalog, called TestDCat, with subtypes of Test Debts and Technical Debt management activities. This catalog is built based on the results of an empirical study, a literature review and semi-structured interviews conducted with practitioners who perform testing activities on five projects from industry. For the TestDCat evaluation, a case study is conducted in real projects in order to identify if the catalog is user-friendly and if its use helps the Test Debt management during the execution of test activities in these software development projects.
Background: Technical debt (TD) has been an important focus of attention in recent years by the scientific community and the software industry. TD is a concept for expressing the lack of internal software quality that directly affects its capacity to evolve. Some studies have focused on the TD industry perspective. Aims: To characterize how the software industry professionals in Uruguay understand, perceive, and adopt technical debt management (TDM) activities. Method: To replicate a Brazilian survey with the Uruguayan software industry and compare their findings. Results: From 259 respondents, many indicated any awareness of the TD concept due to the faced difficult to realize how to associate such a concept with actual software issues. Therefore, it is possible to observe a considerable variability in the importance of TDM among the respondents. However, a small part of the respondents declares to carry out TDM activities in their organizations. A list of software technologies declared as used by practitioners was produced and can be useful to support TDM activities. Conclusions: The TD concept and its management are not common yet in Uruguay. There are indications of TD unawareness and difficulties in the conduction of some TDM activities considered as very important by the practitioners. There is a need for more effort aiming to disseminate the TD knowledge and to provide software technologies to support the adoption of TDM in Uruguay. It is likely other software engineering communities face similar issues. Therefore, further investigations in these communities can be of interest.
Technical debt (TD), as a metaphor for utilizing quick workarounds to achieve short-term wins, is gaining attention in academia and industry. However , little is known about how companies pay off the accumulated TD, or why they chose to avoid this payment. The goal of this research was set to address this knowledge gap by gaining insight on TD payment practices, as well as on reasons behind the decisions to avoid debt payment in the Serbian IT industry. This research is a part of the InsighTD project-a globally distributed family of industrial surveys on TD-and as such it also amplifies the InsighTD reach and expands its knowledge base. A nationwide survey was conducted with practitioners from the Serbian IT industry, which was followed by a qualitative and quantitative data analysis. In total 79 valid responses were analyzed. Results show that TD is in most cases payed off by refactoring or by hiring specialized professionals, while the most common reasons why TD is not payed off include the lack of resources, complexity of the needed repayment work and the lack of management support. Results also suggest that payment of deadline-caused TD with additional work can generate additional TD injections due to tight schedule. This can motivate academics to conduct further empirical investigations while the practitioners can familiarize with practices for paying of the accumulated TD, as well as reasons for avoiding debt payment.
ContextStudying the causes of technical debt (TD) could aid in TD prevention, thus easing the job of TD management. On the other hand, better understanding of the effects of TD could also aid in TD management by facilitating more informed decisions about incurring and paying off debt.Objective
Create a deeper understanding, and confirming existing evidence, of the causes and effects of TD by collecting new evidence from real-world TD examples.Method
InsighTD is a globally distributed family of industrial surveys on the causes and effects of TD. It is designed to run as a large-scale study based on continuous and independent replications in different countries. The survey instrument asks practitioners to describe in detail a real example of TD from their experience. We present in this paper the design of InsighTD, which has the primary goal of replication at a large-scale, with the results of the study in Brazil as a small part of the larger puzzle.ResultsThe first iteration of the InsighTD survey, carried out in Brazil, yielded 107 responses. We identified a total of 78 causes and 66 effects, which confirm and also extend the current knowledge on causes and effects of TD. Then, we organized the identified set of causes and effects in probabilistic cause-effect diagrams. The proposed diagrams highlight the causes that can most contribute to the occurrence of TD as well as the most common effects that occur as a result of debt.Conclusion
We intend to reduce the problem of isolated TD investigations that are not yet representative and build a continuous and generalizable empirical basis for understanding practical problems and challenges of TD.
[Context and Motivation] It is common for teams to take shortcuts during software development that, in the future, will lead to maintainability issues and affect productivity and development cost. Different types of technical debt may affect software projects, including those associated with software documentation. Although there are many studies on technical debt, few focus on documentation debt in an industrial environment. [Question/Problem] We aimed to identify how software practitioners perceive the occurrence of documentation debt in their projects. We present a combined analysis of the results from two complementary studies: a survey (InsighTD) and an interview-based case study. [Principal Ideas/Results] We provide a list of causes and effects of documentation debt, along with practices that can be used to deal with it during software development projects. [Contribution] We find that documentation debt is strongly related to requirements issues. Moreover, we propose a theoretical framework, which provides a comprehensive depiction of the documentation debt phenomenon.
The software startups are a particular scenario where Technical Debt (TD) may occur in an intentional or unintentional way. However, the current knowledge about the perception and management of TD are mainly related to mature software organizations. This chapter contextualizes the startups’ characteristics that can lead to TD incurrence, the concepts related to TD and its management, and presents the results of a survey with Uruguayan software startups. The survey’s primary goal was to understand how software startups perceive and manage TD in their projects. The results refer to the level of understanding of the startup’s practitioners concerning TD concept, the adopted Technical Debt Management (TDM) activities, and the strategies and technologies used in their projects to support such activities. The findings show that startups seem to invest time and effort in TDM activities being TD prevention, one of the most conducted activities. Besides that, it was observed that the participant’s experience and the size of the organization seem to be also related to the perception and management of TD.
Technical debt (TD) is receiving more and more attention to software engineering. Although it was initially used as a communication tool for technical and non-technical stakeholders, nowadays this concept supports the improvement of the software’s internal quality. Despite the increasing number of studies regarding TD and its management, only a few are concerned with the industry. Therefore, this primary study aims to characterize TD and its management under the perspective of Brazilian software organizations using their practitioners as proxies. A survey was performed with 62 practitioners, representing around 12 organizations and 30 software projects. The analysis of 40 valid questionnaires indicates that TD is still unknown to a considerable fraction of the participants, and only a small group of organizations adopt TD management activities in their projects. The survey package is available and can be used to support further investigations on TD management in software organizations.
The technical debt (TD) concept inspires the development of useful methods and tools that support TD identification and management. However, there is a lack of evidence on how different TD identification tools could be complementary and, also, how human-based identification compares with them. To understand how to effectively elicit TD from humans, to investigate several types of tools for TD identification, and to understand the developers’ point of view about TD indicators and items reported by tools. We asked developers to identify TD items from a real software project. We also collected the output of three tools to automatically identify TD and compared the results in terms of their locations in the source code. Then, we collected developers’ opinions on the identification process through a focus group. Aggregation seems to be an appropriate way to combine TD reported by developers. The tools used cannot help in identifying many important TD types, so involving humans is necessary. Developers reported that the tools would help them to identify TD faster or more accurately and that project priorities and current development activities are important to be considered together, along with the values of principal and interest, when deciding to pay off a debt. This work contributes to the TD landscape, which depicts an understanding between different TD types and how they are best discovered.
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.
Reliability and validity describe desirable psychometric characteristics of research instruments. The concept of validity is also applied to research studies and their findings. Internal validity examines whether the study design, conduct, and analysis answer the research questions without bias. External validity examines whether the study findings can be generalized to other contexts. Ecological validity examines, specifically, whether the study findings can be generalized to real-life settings; thus ecological validity is a subtype of external validity. These concepts are explained using examples so that readers may understand why the consideration of internal, external, and ecological validity is important for designing and conducting studies, and for understanding the merits of published research.
In order to effectively manage technical debt (TD), a set of indicators has been used by automated approaches to identify TD items. However, some debt items may not be directly identified using only metrics collected from the source code. CVM-TD is a model to support the identification of technical debt by considering the developer point of view when identifying TD through code comment analysis. In this paper, we investigate the use of CVM-TD with the purpose of characterizing factors that affect the accuracy of the identification of TD, and the most chosen patterns by participants as decisive to indicate TD items. We performed a controlled experiment investigating the accuracy of CVM-TD and the influence of English skills and developer experience factors. We also investigated if the contextualized vocabulary provided by CVM-TD points to candidate comments that are considered indicators of technical debt by participants. The results indicated that CVM-TD provided promising results considering the accuracy values. English reading skills have an impact on the TD detection process. We could not conclude that the experience level affects this process. We identified a list of the 20 most chosen patterns by participants as decisive to indicate TD items. The results motivate us continuing to explore code comments in the context of TD identification process in order to improve CVM-TD.
Sankey diagrams are used to visualise flows of materials and energy in many applications, to aid understanding of losses and inefficiencies, to map out production processes, and to give a sense of scale across a system. As available data and models become increasingly complex and detailed, new types of visualisation may be needed. For example, when looking for opportunities to reduce steel scrap through supply chain integration, it is not enough to consider simply flows of “steel” — the alloy, thickness, coating and forming history of the metal can be critical. This paper combines data-visualisation techniques with the traditional Sankey diagram to propose a new type of “hybrid” Sankey diagram, which is better able to visualise these different aspects of flows.
Context: Integrate research evidence with practice is one of the main goals of evidence-based software engineering. However, recent studies show that the connection between systematic reviews and practitioners has not fully established.
Goal: This paper presents the first steps towards a medium to transfer knowledge acquired from systematic reviews to practitioners.
Method: We selected a set of systematic reviews identified by a tertiary study and extracted their findings to generate one-page Evidence Briefings to serve as mediums. A design specialist defined the briefings structure based on information design and gestalt principles. To evaluate the format and content of the briefings we conducted personal opinion surveys based on two groups: StackExchange users that posted questions in topics related to the reviews, and the authors of the selected reviews themselves. The former had a response rate of 21.9% (32 out 146) and the latter 31.8% (7 out of 22).
Results: Practitioners rarely use systematic review research papers as mediums to acquire knowledge, since just 9% have told to do so. Both researchers and practitioners positively evaluated the evidence briefings, since 71% and 82% of the StackExchange users and systematic review authors, respectively, agreed or strongly agreed that the briefings' interface is clear.
Conclusions: Researchers and practitioners were positive about the content and format of the evidence briefings we proposed. It is also possible to say that there is a gap between practitioners and systematic reviews due to the low percentage of practitioners that consume systematic reviews. The good reception of the evidence briefings from both sides show a possible route to reduce that gap.
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.
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.
Fierce competition in the software market forces companies to release their product under tough time constraints. The competition makes companies reactive and they need to release new versions often. To achieve this need for speed, companies take shortcuts to reach deadlines. These shortcuts and resulting omitted quality are called technical debt. We investigated one middle-size Finnish software company with two independent product lines and interviewed 12 persons in different positions to understand the causes and effects of technical debt. We were also interested in specific strategies and practices for managing technical debt. The results showed that technical debt is mostly formed as a result of intentional decisions made during the project to reach deadlines. Customer satisfaction was identified as the main reason for taking technical debt in short-term but it turned to economic consequences and quality issues in the longer perspective. Interestingly, neither of the product lines had any specific management plan for reducing technical debt but several practices have been identified.
Risk, and related measures of effect size (for categorical outcomes) such as relative risks and odds ratios, are frequently presented in research articles. Not all readers know how these statistics are derived and interpreted, nor are all readers aware of their strengths and limitations. This article examines several measures, including absolute risk, attributable risk, attributable risk percent, population attributable risk percent, relative risk, odds, odds ratio, and others. The concept and method of calculation are explained for each of these in simple terms and with the help of examples. The interpretation of each is presented in plain English rather than in technical language. Clinically useful notes are provided, wherever necessary.
© Copyright 2015 Physicians Postgraduate Press, Inc.
Requirements and requirements documentation debt (R2DD) indicate shortcuts taken in software development projects, resulting in requirements partially implemented and with outdated documentation, respec-tively. Knowing the causes and effects of R2DD can support software teams in defining actions to prevent the occurrence of these items and aid in the prioriti-zation for eliminating them, respectively. Besides, having information on how practitioners deal with R2DD items can support developing new strategies and artifacts for managing these items. However, little is known on the state of the practice of R2DD. [Aims:] To investigate the state of the practice of R2DD, re-vealing its causes, effects, and practices and practice avoidance reasons (PARs) considered for its prevention and repayment. [Method:] We analyzed quantita-tively and qualitatively a corpus of responses from a survey with software prac-titioners on R2DD and its elements (causes, effects, prevention, and repayment). [Results:] We identified 55 causes, 33 effects, 26 prevention practices, three PARs related to nonprevention, 18 repayment practices, and 16 PARs associated with nonrepayment of R2DD items. [Conclusion:] We organized those practices into a conceptual map. Software practitioners can use the map to start or improve their initiatives for dealing with R2DD items.
Context
Technical debt (TD) payment refers to the activity of expending maintenance effort and resources to make up for the effects of previous technical compromises.
Aims
To investigate if software practitioners have paid debt items off in their projects, the practices that have been used for paying off debt items, and the issues that hamper the implementation of these practices.
Method
We analyze 653 responses collected by surveying practitioners from six countries about TD payment.
Results
Practitioners have not paid off TD items in most cases. We identified 27 reasons for not paying off those items and 32 payment-related practices. Practices are mainly related to internal quality issues, while reasons for not paying TD off are mostly associated with planning and management issues. Lastly, we identified relationships between practices and between reasons, indicating that both can appear in combination.
Conclusion
. We use different views to consolidate the set of information on TD payment, extending the conceptual model for TD and organizing the set of practices and reasons into a TD payment map. We believe that the model and the map can support practitioners in planning their TD payment strategy.
This article presents technical debt (TD) impediments, decision factors, enabling practices, and actions diagrams for TD management in agile software projects. By analyzing diagrams, professionals can avoid the pitfalls, and increase their capacity, for better TD management.
Technical Debt (TD) can be injected at any stage of software development. Once injected, TD rarely remains contained and spreads across other stages causing various problems. During software development, technical and non-technical roles need to cooperate and communicate complex issues to implement optimal solutions. This article presents a model for conceptualizing TD causes, effects, payment practices, and payment avoidance reasons with a prioritization schema for technical and non-technical roles. The model is based on the analysis of 168 responses from TD-experienced practitioners and aims to support: (a) communication-by highlighting the similarities and differences between two perspectives, and (b) complementing the existing TD management and prioritization approaches with a conceptual model that takes into consideration the contextual factors and presents them in a form of prioritized lists of the most significant factors.
Context
Architectural decisions are considered one of the most common sources of technical debt (TD). Thus, it is necessary to understand how TD is perceived by software architects, particularly, the practices supporting the elimination of debt items from projects, and the practices used to reduce the chances of TD occurrence.
Objective
This paper investigates the most commonly used practices to pay off TD and to prevent debt occurrence in software projects from the architect’s point of view.
Method
We used the available data from InsighTD, which is a globally distributed family of industrial surveys on the causes, effects, and management of TD. We analyze responses from a corpus of 72 software architects from Brazil, Chile, Colombia, and the United States.
Results
Results showed that refactoring (30.2%) was the main practice related to TD payment, followed by design improvements (14.0%). Refactoring, design improvements, and test improvements are the most cited payment practices among cases of code, design and test debt. Concerning the TD preventive practices, we find that having a well-defined architecture and design is the most cited practice (13.6%), followed by having a well-defined scope and requirements. This last practice is the most cited one for expert software architects. Finally, when comparing preventive practices among the three major roles derived from the survey (software architects, engineer roles, and management roles), we found that none of the roles shared the most cited practice, meaning that each role had its worries and focus on different strategies to reduce TD’s presence in the software.
Conclusion
The lists of TD payment and prevention practices can guide software teams by having a catalog of practices to keep debt controlled or reduced.
Background: Technical Debt (TD) refers to the problem of pending or incomplete tasks and artifacts that brings short term gain to a software project, but may have to be paid with interest later on in its life-cycle. We use the term test-related debt to refer to TD items faced by software testing practitioners. Goal: To investigate, from the point of view of software testing practitioners, TD types associated with test-related debt, the causes that lead to it, and the effects of its existence. Method: We perform a replication of a well-known TD survey with software testing practitioners and combine the obtained responses with the ones collected in the original study. In total, the study analyses, quantitatively and qualitatively, 54 responses from Brazilian testing practitioners. Results: Test-related debt items are associated with TD types such as documentation, code, and test debt itself. The survey identified 61 TD causes that are organized into eight categories. The main causes are deadline, outdated / incomplete documentation, and inappropriate planning. The survey identified 45 TD effects that are grouped into six categories. The main effects are delivery delay, rework, and low external quality. Conclusion: This paper organizes the identified causes and effects in probabilistic cause-effect diagrams, which provide a broad view of the state of the practice concerning test-related debt causes and effects.
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 nationwide 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.
Background: There is a growing body of knowledge on Technical Debt (TD) in recent years. This knowledge provides various explanations of the term and suggests different remedies for it. However, the knowledge is yet to be validated in software development
processes. Aims: The objective of this study is twofold. First, to get empirical insight on the understanding and the use of the TD concept in Serbian IT industry. Second, to contribute towards precise conceptualization of the TD concept. Method:We conducted
a national-wide survey to collect feedback from industry practitioners.The survey is a part of InsighTD–an international initiative to investigate causes and effects of TD. Results: In total, 93 responses were collected, mostly from developers. Results indicate that the
concept of TD is not widely accepted for use by the industry, only 35% of practitioners have practical experiences with projects that explicitly considered or managed TD. The most common types of TD are: code, test and design debt that together account for 61%
of all reported cases. The archetypal TD case is caused by a tight schedule and resulted with non-optimal solutions that are difficult to evolve and in constant need of rework. Conclusions: Implications are at one hand for academics, who should consider TD as a topic for their curriculums since the results revealed that novice developers are unfamiliar with the concept. At the other hand, industry practitioners have a well aligned understanding of the TD concept, which is consistent with TD literature. However, we perceive that the wider use of the existing tools and techniques for managing TD can significantly help practitioners to deal with the top three occurring TD types.
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.
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 refactor-ing (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
The current software development scenario is characterized by a wide adoption of agile methodologies. Despite its benefits, agile software development (ASD) is also vulnerable to technical debt (TD). In fact, due to its delivery-oriented nature, ASD seems to be more prone to TD accumulation than traditional software development. Although the concept of TD has been increasingly investigated in software engineering, there is a lack of studies regarding TD in ASD. This paper discusses the most common causes and effects of TD in ASD. Through an industrial survey on TD, we compiled the answers of 51 practitioners to identify 43 causes and 30 effects of TD in ASD. This information can support decision-makers on how to deal with TD in agile software development.
InsighTD is a globally distributed family of industrial surveys on causes and effects of Technical Debt (TD). We are currently analyzing the data gathered from the independent replication of the questionnaire in Costa Rica. In total, 156 professionals from the Costa Rican software industry answered the survey. Initial results indicate that there is a broad familiarity with the concept of TD. For the examples reported, it seems that the type of TD were product of situations that could have been prevented. TD was monitored for slightly more than half of cases, and TD was not paid in most cases. In future articles, we will report causes and the effects of TD in Costa Rica.
Context: The concept of technical debt (TD) contextualizes problems faced during software evolution considering the tasks that are not carried out adequately during its development. Currently, it is common to associate any impediment related to the software product and its development process to the definition of TD. This can bring confusion and ambiguity in the use of the term. Besides, due to the increasing amount of work in the area, it is difficult to have a comprehensive view of the plethora of proposals on TD management. Objective: This paper intends to investigate the current state of research on TD by identifying what research topics have been considered, organizing research directions and practical knowledge that has already been defined, identifying the known types of TD, and organizing what activities, strategies and tools have been proposed to support the management of TD. Method: A tertiary study was performed based on a set of five research questions. In total, 13 secondary studies, dated from 2012 to March 2018, were evaluated. Results: The results of this tertiary study are beneficial for both practitioners and researchers. We evolved a taxonomy of TD types, identified a list of situations in which debt items can be found in software projects, and organized a map representing the state of the art of activities, strategies and tools to support TD management. Besides, we also summarized some research directions and practical knowledge, and identified the research topics that have been more considered in secondary studies. Conclusion: This tertiary study revisited the TD landscape. Its results can help to identify points that still require further investigation in TD research.
Tackling the issues of technical debt in a large system in parallel with continuing to enable it to evolve is a challenging problem.
In this paper, we are describing a case study of managing technical debt on a legacy project referred here as Global Configurator Project (GCP) using pragmatic approach. The paper presents holistic lifecycle approach with four stages and various practices in each stage for managing technical debt. Given life cycle approach and practices will be useful for any software project. In particular, these practices will be significant to any legacy project towards repaying debt. These methods can also be applied to continuously improve code quality and product quality. This paper also focus on technical debt user stories to gain business buy-in and share few 'best in market' tools that we used in repaying technical debt. It also focuses on sensitizing developers to the concept of debt and improving their skills. This paper describes the process used by a separate team formed to reduce technical debt in a large legacy system.
The paper targets to the Project Managers, Test Managers architects and Scrum Masters in agile software development.
The technical debt metaphor is widely used to encapsulate numerous software quality problems. The metaphor is attractive to practitioners as it communicates to both technical and nontechnical audiences that if quality problems are not addressed, things may get worse. However, it is unclear whether there are practices that move this metaphor beyond a mere communication mechanism. Existing studies of technical debt have largely focused on code metrics and small surveys of developers. In this paper, we report on our survey of 1,831 participants, primarily software engineers and architects working in long-lived, software-intensive projects from three large organizations, and follow-up interviews of seven software engineers. We analyzed our data using both nonparametric statistics and qualitative text analysis. We found that architectural decisions are the most important source of technical debt. Furthermore, while respondents believe the metaphor is itself important for communication, existing tools are not currently helpful in managing the details. We use our results to motivate a technical debt timeline to focus management and tooling approaches.
Software is being produced at such a rate that its growth hinders its sustainability. Technical debt, as a concept encompassing internal software quality, evolution and maintenance, re-engineering and economics is growing to become dominant as a driver of progress in the future of software engineering. Technical debt spans the entire software engineering lifecycle and its management capitalizes on recent advances made in fields such as source code analysis, quality measurement, and project management. Managing technical debt in the future will be an investment activity applying economics theories, will effectively address the architecture level, will offer specific processes and tools employing data science and analytics to support decision making, and will 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 from theory to its applications.