Reducing Technical Debt through Strategic Leadership in Retail Technology Systems

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

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

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.

The impact of Technical Debt (TD) on software maintenance and evolution is of great concern, but recent evidence shows that a considerable amount of TD is fixed by the same developers who introduced it; this is termed self-fixed TD. This characteristic of TD management can potentially impact team dynamics and practices in managing TD. However, the initial evidence is based on low-level source code analysis; this casts some doubt whether practitioners repay their own debt intentionally and under what circumstances. To address this gap, we conducted an online survey on 17 well-known Java and Python open-source software communities to investigate practitioners' intent and rationale for self-fixing technical debt. We also investigate the relationship between human-related factors (e.g., experience) and self-fixing. The results, derived from the responses of 181 participants, show that a majority addresses their own debt consciously and often. Moreover, those with a higher level of involvement (e.g., more experience in the project and number of contributions) tend to be more concerned about self-fixing TD. We also learned that the sense of responsibility is a common self-fixing driver and that decisions to fix TD are not superficial but consider balancing costs and benefits, among other factors. The findings in this paper can lead to improving TD prevention and management strategies.

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

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.

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 (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.

One of the first steps towards the effective Technical Debt (TD) management is the quantification and continuous monitoring of the TD principal. In the current state-ofresearch and practice the most common ways to assess TD principal are the use of: (a) structural proxies—i.e., most commonly through quality metrics; and (b) monetized proxies—i.e., most commonly through the use of the SQALE (Software Quality Assessment based on Lifecycle Expectations) method. Although both approaches have merit, they seem to rely on different viewpoints of TD and their levels of agreement have not been evaluated so far. Therefore, in this paper, we empirically explore this relation by analyzing data obtained from 20 open source software projects and build a regression model that establishes a relationship between them. The results of the study suggest that a model of seven structural metrics, quantifying different aspects of quality (i.e., coupling, cohesion, complexity, size, and inheritance) can accurately estimate TD principal as appraised by SonarQube. The results of this case study are useful to both academia and industry. In particular, academia can gain knowledge on: (a) the reliability and agreement of TD principal assessment methods and (b) the structural characteristics of software that contribute to the accumulation of TD, whereas practitioners are provided with an alternative evaluation model with reduced number of parameters that can accurately assess TD, through traditional software quality metrics and tools.

Technical debt refers to decisions made during the design and development of software that postpone the resolution of technical problems or the enhancement of the software’s features to a later date. If not properly managed, technical debt can put long-term software quality and maintainability at risk. Self-admitted technical debt is defined as the addition of specific comments to source code as a result of conscious and deliberate decisions to accumulate technical debt. In this paper, we will look at the presence of self-admitted technical debt in open-source blockchain projects, which are characterized by the use of a relatively novel technology and the need to generate trust. The self-admitted technical debt was analyzed using NLP techniques for the classification of comments extracted from the source code of ten projects chosen based on capitalization and popularity. The analysis of self-admitted technical debt in blockchain projects was compared with the results of previous non-blockchain open-source project analyses. The findings show that self-admitted design technical debt outnumbers requirement technical debt in blockchain projects. The analysis discovered that some projects had a low percentage of self-admitted technical debt in the comments but a high percentage of source code files with debt. In addition, self-admitted technical debt is on average more prevalent in blockchain projects and more equally distributed than in reference Java projects.If not managed, the relatively high presence of detected technical debt in blockchain projects could represent a threat to the needed trust between the blockchain system and the users. Blockchain projects development teams could benefit from self-admitted technical debt detection for targeted technical debt management.

Chapter 2 - Measuring and Monitoring 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).