Technical Debt Management Research Articles

Prevalence, common causes and effects of technical debt: Results from a family of surveys with the IT industry

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.

On the Relationship Between Technical Debt Management and Process Models

This study investigates the potential relationship between development process models and technical debt effects and their management by surveying 432 practitioners from software organizations in Brazil, Chile, Colombia, and the United States.

TestDCat 3.0: catalog of test debt subtypes and management activities

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.

Experience With Managing Technical Debt in Scientific Software Development Using the EXA2PRO Framework

Technical Debt (TD) is a software engineering metaphor that resembles the production of poor-quality code to going into debt. In particular, a development team that “ saves ” effort while developing by not removing inefficiencies, has to “ pay-back ” with interest, in the form of additional maintenance costs (i.e., fixing bugs, adding features, etc.) due to the poor maintainability of the developed code. Although maintainability assurance is an established practice in traditional software development (lately known as TD management), it has still not attracted the attention of scientific software developers; i.e., researchers writing code and developing tools for purely research purposes. Nevertheless, based on the literature and practice, maintainability seems to be ranked as an important key-driver for the development of such applications; since the effort needed to update the code before the experimentation (e.g., executing a simulation) is common and should not receive low priority. In this paper, we present the outcome of a 3-year research project on Technical Debt Management (TDM) for scientific software development. The outcome of the project is a framework (termed: EXA2PRO TDM framework) and an accompanying platform for assisting scientific software developers in managing the TD of their applications. The framework is a collection of methods tailored for the mainstream programming languages of scientific software development, which have been empirically validated through five pilot applications. The majority of the EXA2PRO framework suggestions have been applied by scientific software developers and eased future maintenance activities.

Exploring the Relation between Technical Debt Principal and Interest: An Empirical Approach

The cornerstones of technical debt (TD) are two concepts borrowed from economics: principal and interest. Although in economics the two terms are related, in TD there is no study on this direction so as to validate the strength of the metaphor. We study the relation between Principal and Interest, and subsequently dig further into the ‘ingredients’ of each concept (since they are multi-faceted). In particular, we investigate if artifacts with similar levels of TD Principal exhibit a similar amount of TD Interest, and vice-versa. To achieve this goal, we performed an empirical study, analyzing the dataset using the Mantel test. Through the Mantel test, we examined the relation between TD Principal and Interest, and identified aspects that are able to denote proximity of artifacts, with respect to TD. Next, through Linear Mixed Effects (LME) modelling we studied the generalizability of the results. The results of the study suggest that TD Principal and Interest are related, in the sense that classes with similar levels of TD Principal tend to have similar levels of Interest. Additionally, we have reached the conclusion that aggregated measures of TD Principal or Interest are more capable of identifying proximate artifacts, compared to isolated metrics. Finally, we have provided empirical evidence on the fact that improving certain quality properties (e.g., size and coupling) should be prioritized while ranking refactoring opportunities in the sense that high values of these properties are in most of the cases related to artifacts with higher levels of TD Principal. The findings shed light on the relations between the two concepts, and can be useful for both researchers and practitioners: the former can get a deeper understanding of the concepts, whereas the latter can use our findings to guide their TD management processes such as prioritization and repayment.

A computational model of a natural language processing system for architectural technical debt management

Technical debt is a concept applied to decisions taken to favor rapid production, at the expense of future capacities to evolve or improve the product or service. This concept is transversal to all sciences, especially in experimental physics and systems. However, technical debt is difficult to manage because there is a lack of time, expertise, or knowledge on how to perform it. This paper proposes a computational model of technical debt management in software architecture, based on observations made in software teams in their daily work. This computational model exploits natural language processing and model-testing techniques on software project artifacts to build a model that allows localizing and visualizing the impact produced by the technical debt and its payment strategies. This proposal aims to support teams of architects to explain the current and future impact of the debt injected as a result of decisions made.

Developing a theory based on the causes of technical debt injection into software projects in Colombia

Engineering, like sciences such as physics, seeks to ensure that the conclusions reached can be verified through experiments, and that subsequent theories allow predictions to be made in future observations. This procedure is applied in this article, whose objective is the identification of the causes that favor the injection or presence of technical debt, and its application in software projects in Colombia, to build a theory that allows explaining this behavior. In turn, these causes could be also extrapolated to physical research projects. Results showed that “focus on producing more at the expense of quality” is the most cited cause in general. Conversely, “planning and management” is the most cited category of causes of technical debt. The concept of technical debt is well understood by software practitioners and that most efforts need to be invested by researchers on offering strategies and tools to support technical debt management.

The practitioners’ point of view on the concept of technical debt and its causes and consequences: a design for a global family of industrial surveys and its first results from Brazil

Studying 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. Create a deeper understanding, and confirming existing evidence, of the causes and effects of TD by collecting new evidence from real-world TD examples. 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. The 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. 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.

The influence of Technical Debt on software developer morale

ContextPrevious research in the Technical Debt (TD) field has mainly focused on the technical and economic aspects, while its human aspect has received minimal attention. ObjectiveThis paper aims to understand how software developers’ morale is influenced by TD and how their morale is influenced by TD management activities. Furthermore, this study correlates the morale with the amount of wastage of time due to TD. MethodFirstly, we conducted 15 interviews with professionals, and, secondly, these data were complemented with a survey. Thirdly, we collected 473 data points from 43 developers reporting their amount of wasted time. The collected data were analyzed using both quantitative and qualitative techniques, including thematic and statistical analysis. ResultsOur results show that the occurrence of TD is associated with a lack of progress and waste of time. This might have a negative influence on developers’ morale. Further, management of TD seems to have a positive influence on developers’ morale. ConclusionsThe results highlight the effects TD has on practitioners’ software work. This study presents results indicating that software suffering from TD reduces developers’ morale and thereby also their productivity. However, our results also indicate that TD management increases developers’ morale and developer productivity.

A Taste of the Software Industry Perception of Technical Debt and its Management in Brazil

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.

Understanding automated and human-based technical debt identification approaches-a two-phase study

ContextThe 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.ObjectiveTo 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.MethodWe 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.ResultsAggregation 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.ConclusionThis work contributes to the TD landscape, which depicts an understanding between different TD types and how they are best discovered.

Integrating Technical Debt Management and Software Quality Management Processes: A Normative Framework and Field Tests

Despite the increasing awareness of the importance of managing technical debt in software product development, systematic processes for implementing technical debt management in software production have not been readily available. In this paper we report on the development and field tests of a normative process framework that systematically incorporates steps for managing technical debt in commercial software production. The framework integrates processes required for technical debt management with existing software quality management processes prescribed by the project management body of knowledge (PMBOK), and it contributes to the further development of software-specific extensions to the PMBOK. We partnered with three commercial software product development organizations to implement the framework in real-world software production settings. All three organizations, irrespective of their varying software process maturity levels, were able to adopt the proposed framework and integrate the prescribed technical debt management processes with their existing software quality management processes. Our longitudinal observations and case-study interviews indicate that the organizations were able to accrue economic benefits from the adoption and use of the integrated framework.

Technical debt and agile software development practices and processes: An industry practitioner survey

Context: Contemporary software development is typically conducted in dynamic, resource-scarce environments that are prone to the accumulation of technical debt. While this general phenomenon is acknowledged, what remains unknown is how technical debt specifically manifests in and affects software processes, and how the software development techniques employed accommodate or mitigate the presence of this debt.Objectives: We sought to draw on practitioner insights and experiences in order to classify the effects of agile method use on technical debt management, given the popularity and perceived success of agile methods. We explore the breadth of practitioners’ knowledge about technical debt; how technical debt is manifested across the software process; and the perceived effects of common agile software development practices and processes on technical debt. In doing so, we address a research gap in technical debt knowledge and provide novel and actionable managerial recommendations.Method: We designed, tested and executed a multi-national survey questionnaire to address our objectives, receiving 184 responses from practitioners in Brazil, Finland, and New Zealand.Results: Our findings indicate that: 1) Practitioners are aware of technical debt, although, there was under utilization of the concept, 2) Technical debt commonly resides in legacy systems, however, concrete instances of technical debt are hard to conceptualize which makes it problematic to manage, 3) Queried agile practices and processes help to reduce technical debt; in particular, techniques that verify and maintain the structure and clarity of implemented artifacts (e.g., Coding standards and Refactoring) positively affect technical debt management.Conclusions: The fact that technical debt instances tend to have characteristics in common means that a systematic approach to its management is feasible. However, notwithstanding the positive effects of some agile practices on technical debt management, competing stakeholders’ interests remain a concern.

Technical Debt in Agile Development

We report on the Ninth International Workshop on Managing Technical Debt, collocated with the 18th International Conference on Agile Software Development (XP 2017) in Cologne. The technical debt research community continues to expand through collaborations of industry, tool vendors, and academia. The theme of this year's workshop was on technical debt in agile development. Presentations and discussion centered on the topics: technical debt at the code level, architectural technical debt assessment, agile approaches and their impact on technical debt management, and selling the business case of technical debt management.

Identification and analysis of the elements required to manage technical debt by means of a systematic mapping study

Identification and classification of the elements to manage technical debt (TD).The classification resulted in a framework including the stakeholders interests.The industrial relevance of current support to elements was assessed.The framework is a basis for building TD decision-making models.It was found out that TD management decisions are context-dependent. Technical debt, a metaphor for the long-term consequences of weak software development, must be managed to keep it under control. The main goal of this article is to identify and analyze the elements required to manage technical debt. The research method used to identify the elements is a systematic mapping, including a synthesis step to synthesize the elements definitions. Our perspective differs from previous literature reviews because it focused on the elements required to manage technical debt and not on the phenomenon of technical debt or the activities used in performing technical debt management. Additionally, the rigor and relevance for industry of the current techniques used to manage technical debt are studied. The elements were classified into three groups (basic decision-making factors, cost estimation techniques, practices and techniques for decision-making) and mapped according three stakeholders' points of view (engineering, engineering management, and business-organizational management). The definitions, classification, and analysis of the elements provide a framework that can be deployed to help in the development of models that are adapted to the specific stakeholders' interests to assist the decision-making required in technical debt management and to assess existing models and methods. The analysis indicated that technical debt management is context dependent.

Technical Debt as an Indicator of Library Metadata Quality

Metadata production is a significant cost for any digital library program. As such, care should be taken to ensure that when metadata is created, it is done in such a way that its quality will not be low enough to be a liability to current and future library applications. Agile software development uses the concept of to place metrics on the ongoing costs associated with low-quality code, and determine resource allocation for strategies to improve it. This paper applies the technical debt metaphor in the context of metadata management, identifying common themes across the qualitative and quantitative literature related to technical debt, and connecting it to similar themes in the literature on metadata quality assessment. It concludes with areas of future research in the area of technical debt and metadata management, and ways in which the metaphor may be integrated into other current avenues of metadata research.

Costs and obstacles encountered in technical debt management – A case study

Technical debt (TD) is a metaphor that characterizes the effect of immature software artifacts. The costs and benefits of TD, along with the uncertainty of its interest repayment, provide leverage for software managers, but also could lead to problems such as increased costs and lower quality during maintenance if it is left unattended. Therefore, effective approaches to TD management are needed by software practitioners. As one of our series of studies on TD management, this study was originally designed to reveal the cost side of explicit TD management. The study design required applying a simple proposed TD management approach to the subject project and then collecting cost information. Not surprisingly, we observed some deviation of the actual management process from our proposed one, which provided us with an opportunity to investigate the obstacles to explicitly managing TD. We also identified some costs and cost patterns related to TD management. Based on the insights gained from this study, we further propose strategies to overcome the obstacles and improve the application of TD management in practice.

How do software development teams manage technical debt? – An empirical study

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.

Identification and management of technical debt: A systematic mapping study

ContextThe technical debt metaphor describes the effect of immature artifacts on software maintenance that bring a short-term benefit to the project in terms of increased productivity and lower cost, but that may have to be paid off with interest later. Much research has been performed to propose mechanisms to identify debt and decide the most appropriate moment to pay it off. It is important to investigate the current state of the art in order to provide both researchers and practitioners with information that enables further research activities as well as technical debt management in practice. ObjectiveThis paper has the following goals: to characterize the types of technical debt, identify indicators that can be used to find technical debt, identify management strategies, understand the maturity level of each proposal, and identify what visualization techniques have been proposed to support technical debt identification and management activities. MethodA systematic mapping study was performed based on a set of three research questions. In total, 100 studies, dated from 2010 to 2014, were evaluated. ResultsWe proposed an initial taxonomy of technical debt types, created a list of indicators that have been proposed to identify technical debt, identified the existing management strategies, and analyzed the current state of art on technical debt, identifying topics where new research efforts can be invested. ConclusionThe results of this mapping study can help to identify points that still require further investigation in technical debt research.

Exploring the costs of technical debt management – a case study

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.