Do practitioners intentionally self-fix Technical Debt and why?

Identification and management of technical debt: A systematic mapping study

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

Technical debt are those convenience tasks that developers perform to obtain short-term benefits but that in the future can produce activities that are difficult to perform or more costly. The impact of technical debt is perceived in all project resources, becoming a present and future problem in software development, affecting the quality of the software. This study uses a qualitative analysis, through interviews with a software development team, explores the knowledge and perception of technical debt, the practices used to manage it, the factors that influence its appearance and accumulation, the impact that development suffers, as well as the team and the maintainability of the software, as a result, ideas and solutions are proposed to address it effectively. The study was carried out with a qualitative investigative approach, which was based on the study of a single case with which the experiences and practices in the perception and management of technical debt are investigated. The data obtained reveal that technical debt affects the normal development of the development team and that it is present in the activities carried out by the team. Although the development team has a perception of the debt, it does not address it directly, and it is necessary to implement good practices to identify it and integrate it into the software development process. Addressing technical debt with the implementation of a formal process to manage it will ensure that scheduled time is controlled and resources are optimized, which will result in a culture of good practices that will ensure product quality, improving team performance and guaranteeing software maintainability

The relation between technical debt and corrective maintenance in PHP web applications

In the fast-paced and highly competitive landscape of retail, the management of technical debt has become a critical challenge for organizations striving to maintain robust and scalable technology systems. Technical debt, the accumulated cost of prioritizing quick fixes or suboptimal solutions over more sustainable and efficient options, can significantly hinder an organization's ability to innovate, adapt, and grow. This paper explores the role of strategic leadership in effectively reducing technical debt within retail technology systems. By examining key leadership strategies, such as fostering a culture of continuous improvement, investing in long-term technology planning, and emphasizing cross-functional collaboration, the paper highlights how retail organizations can systematically address and mitigate technical debt. Strategic leadership in the retail sector involves a comprehensive understanding of both business and technological imperatives. Leaders must recognize the implications of technical debt not only in terms of immediate financial costs but also in the broader context of business agility, customer experience, and competitive advantage. The paper emphasizes the need for leaders to adopt a proactive approach, prioritizing technical debt reduction as a strategic objective that aligns with the organization's overall goals. One of the central arguments of the paper is that effective technical debt management requires a shift from reactive to proactive leadership. This involves anticipating potential issues, encouraging innovation, and making informed decisions that balance short-term gains with long-term sustainability. The paper discusses various leadership practices that contribute to this shift, including the implementation of robust governance frameworks, the adoption of agile methodologies, and the promotion of a learning-oriented organizational culture.

The technical debt metaphor is increasingly being used to describe the effect of delaying certain software maintenance tasks on software projects. Practitioners understand intuitively how technical debt can turn into a serious problem if it is left unattended. However, it remains unknown how serious the problem is and whether explicit measurement and management of technical debt is useful. In this paper, we explore the effect of technical debt by tracking a single delayed maintenance task in a real software project throughout its lifecycle and simulate how explicit technical debt management might have changed project outcomes. The results from this study demonstrate how and to what extent technical debt affects software projects. The study also sheds light on the research methodologies that can be used to investigate the technical debt management problem.

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

Chapter 2 - Measuring and Monitoring Technical Debt

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.

Understanding the impact of technical debt is critical to understanding a team's velocity. For organizations with multiple teams and products, the impact of technical debt combines non-linearly to impact the organization's velocity. We can think of the capacity of a team as a portfolio. Not all of that capacity can be invested in new features or defect fixing, without incurring negative consequences. A portion of the team's capacity needs to be invested in the ongoing management and reduction of technical debt. This paper describes a simple technique for visualizing, quantifying and tracking a team's technical debt as a portion of their overall capacity investment. The knowledge and insights gained through this technique help with better capacity planning, improved forecasting, and helps to justify the business case for investing in managing and reducing technical debt.

Technical Debt arises from decisions that favour short-term outcomes at the cost of longer-term disadvantages. They may be taken knowingly or based on missing or incomplete awareness of the costs; they are taken in different roles, situations, stages and ways. Whatever technical or business factor motivate such decisions, they always imply a trade-off in time, a 'now vs. later'. How exactly are such decisions made, and how have they been studied? This paper analyzes how decisions on technical debt are studied in software engineering via a systematic literature review. It examines the presently published Software Engineering research on Technical Debt, with a particular focus on decisions involving time. The findings reveal surprising gaps in published work on empirical research in decision making. We observe that research has rarely studied how decisions are made, even in papers that focus on the decision process. Instead, most attention is focused on engineering measures and feeding them into an idealized decision making process. These findings lead to a set of recommendations for future empirical research on Technical Debt.

Technical debt is a concept used to describe the lack of good practices during software development, leading to several problems and costs. Identification and management strategies can help reduce these difficulties. In a previous study, Alves et al. (2016) analyzed the research landscape of such strategies from 2010 to 2014. This paper replicates and updates their study to explore the evolution of technical debt identification and management research landscape over a decade, including literature from 2010 until 2022. We analyzed 117 papers from the ACM Digital Library, IEEE Xplore, Science Direct, and Springer Link. Newly suggested strategies include automatically identifying admitted debt in comments, commits, and source code. Between 2015 and 2022, more empirical evaluations have been performed, and the general research focus has changed to a more holistic approach. Therefore, the research area evolved and reached a new level of maturity compared to previous results from Alves et al. (2016). Not only are code aspects considered for technical debt, but other aspects have also been investigated (e.g., models for the development process).

Technical debt (TD) is a metaphor that reflects the technical compromises that sacrifice the long-term health of a software product to achieve short term benefit. It is important to manage TD to avoid software degradation. In large-scale distributed projects, technical debt management (TDM) becomes more complex and challenging. There is a lack of empirical studies on the TD accumulation in large-scale distributed projects. Then, to address this gap, we conducted a case study in Ericsson (a European Telecom Company) to identify the relationship between TD accumulation and factors such as task complexity, lead time, total of developers, and task scaling. We used data from 33 projects extracted from managerial documents to conduct a regression analysis. We also conducted interviews with seniors developers of the team to interpret the results. We found out that Task Complexity has a strong relationship (p-value = 5.69 × 10-5) with Technical Debt, while Global Distance was mentioned by the interviewees as a relevant factor for TD accumulation (although not statistically significant in our regression analysis). Practitioners should consider avoiding complex/big tasks, breaking down big tasks into small ones (if possible). We also plan to analyze other projects in this company to confirm our findings further. © 2021 IEEE.

When the culture and processes of software development companies do not support technical debt management, unintentional technical debt accumulates in the system and becomes excessive. Encouragement, dedicated time, and proper processes can reduce and avoid unintentional debt, and the skill of contextual ambidexterity can be applied by creating an encouraging context that supports technical debt management. However, existing literature discussing which contextual factors are required to achieve this skill is scarce, and practitioners call for approaches to reduce and avoid technical debt. This paper presents a systematic literature review of 48 papers to identify contextual factors for achieving contextual ambidexterity in knowledge-driven contexts. The results reveal seven categories of core and support contextual factors. This paper informs small- and medium-sized software development companies which contextual factors establish an encouraging context, and it theoretically examines the IT managers’ responsibility for technical debt management.

Technical Debt (TD) is a metaphor to refer to events that bring quality loss in the code. A large volume of Technical Debt in an application may bring losses for the organisation that keeps it. For those organisations that outsource software development, monitoring TD in the influx of development packages may be an efficient strategy to ensure the quality of the product acquired. This works bring an account on the search for a TD management model, to allow a given Brazilian Federal Administration body to inspect how much debt an application has, as acquired in an outsourced way.