Validating and prioritizing quality rules for managing technical debt: An industrial case study

Cross-disciplinary and cross-life-cycle-phase Technical Debt in automated Production Systems: two industrial case studies and a survey

Technical debt (TD) is a concept used to describe a sub-optimal solution of a software artifact that negatively affects its comprehensibility, extendability and maintainability. As such, TD adversely affects the costs or quality associated with the artifact, which is also called interest. TD has through research been identified in all types of software artifacts, from architectural design to automated tests (Testware). However, research into testware technical debt (TTD) is limited and primarily focused on testing on lower level of system abstraction, i.e. unit-and integration tests, leaving a need for more TTD research on GUI-based testing. In this study we explore this gap in knowledge through an industrial case study at a Swedish avionics software development company. Four repositories are studied for the presence of TTD using expert interviews, semi-automated document analysis and automatic metric analysis. Results of the study provide initial support that the concept of TTD is applicable to GUI-based testware and show the presence of both TD items unique to GUI-based testware and items common to software. The implications of these results are that engineering best practices must be established for GUI-based testware to minimize TD interest.

Background: The COVID-19 outbreak interrupted regular activities for over a year in many countries and resulted in a radical change in ways of working for software development companies, i.e., most software development companies switched to a forced Working-From-Home (WFH) mode. Aim: Although several studies have analysed different aspects of forced WFH mode, it is unknown whether and to what extent WFH impacted the accumulation of technical debt (TD) when developers have different ways to coordinate and communicate with peers. Method: Using the year 2019 as a baseline, we carried out an industrial case study to analyse the evolution of TD in five components that are part of a large project while WFH. As part of the data collection, we carried out a focus group with developers to explain the different patterns observed from the quantitative data analysis. Results: TD accumulated at a slower pace during WFH as compared with the working-from-office period in four components out of five. These differences were found to be statistically significant. Through a focus group, we have identified different factors that might explain the changes in TD accumulation. One of these factors is responsibility diffusion which seems to explain why TD grows faster during the WFH period in one of the components. Conclusion: The results suggest that when the ways of working change, the change between working from office and working from home does not result in an increased accumulation of TD.

Technical Debt tracking: Current state of practice

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.

Concretely communicating technical debt and its consequences is of common interest to both researchers and software engineers. In the absence of validated tools and techniques to achieve this goal with repeatable results, developers resort to ad hoc practices. Most commonly they report using issue trackers or their existing backlog management practices to capture and track technical debt. In a manual examination of 1,264 issues from four issue trackers from open source industry and government projects, we identified 109 examples of technical debt. Our study reveals that technical debt and its related concepts have entered the vernacular of developers as they discuss development tasks through issue trackers. Even when issues are not explicitly tagged as technical debt, it is possible to identify technical debt items in these issue trackers using a categorization method we developed. We use our results and data to motivate an improved definition and an approach to explicitly report technical debt in issue trackers.

Technical debt (TD), its impact on development and its consequences such as defects and vulnerabilities, are of common interest and great importance to software researchers and practitioners. Although there exist many studies investigating TD, the majority of them focuses on identifying and detecting TD from a single stage of development. There are also studies that analyze vulnerabilities focusing on some phases of the life cycle. Moreover, several approaches have investigated the relationship between TD and vulnerabilities, however, the generalizability and validity of findings are limited due to small dataset. In this study, we aim to identify TD through multiple phases of development, and to automatically measure it through data and text mining techniques to form a comprehensive feature model. We plan to utilize neural network based classifiers that will incorporate evolutionary changes on TD measures into predicting vulnerabilities. Our approach will be empirically assessed on open source and industrial projects.

JavaScript (JS) is one of the most popular programming languages for developing client-side applications mainly due to allowing the adoption of different programming styles, not having strict syntax rules, and supporting a plethora of frameworks. The flexibility that the language provides may accelerate the development of application, but also pose threats to the quality of the final software product, e.g., introducing Technical Debt (TD). TD reflects the additional cost of software maintenance activities to implement new features, occurring due to poorly developed solutions. Being able to forecast the levels of TD in the future can be extremely valuable in managing TD, since it can contribute to informed decision making when designating future repayments and refactoring budget among a company's projects. Despite the popularity of JS and the undoubtful benefits of accurate TD forecasting, in the literature, there is available only a limited number of tools and methodologies that are able to: (a) forecast TD during software evolution, (b) provide a ground-truth TD quantifications to train forecasting, since TD tools that are available are based on different rulesets and none is recognized as a state-of-the-art solution, (c) take into consideration the language-specific characteristics of JS. As a main contribution for this study, we propose a methodology (along with a supporting tool) that supports the aforementioned goals based on the Backward Stepwise Regression and Auto-Regressive Integrated Moving Average (ARIMA). We evaluate the proposed approach through a case study on 19,636 releases of 105 open-source applications. The results point out that: (a) the proposed model can lead to an accurate prediction of TD, and (b) the Number of appearances of the “new” and “eval” keyword along with the number of “anonymous” and “arrow” functions are among the features of JavaScript language that are related to high levels of TD.

Technical Debt is a term coined by Ward Cunningham to denote the amount of rework required to put a piece of software into that state which it should have had from the beginning. The term outdates the agile revolution. Technical debt can occur using any development approach, but since agile development has become wide spread the notion of “technical debt” has gained much more attention. That is because if agile development is not done properly, technical debt accrues very fast and threatens to strangle the project. In this paper the author describes how technical debt comes to being, how it can be measured and what can be done to prevent it in agile development. The emphasis of the paper is on how to prevent it. What measures are necessary in an agile development project to keep technical debt from accruing over time? The paper lists out a number of measures which can be taken – organizational, procedural and technical. Automated tools play an important role in the struggle against technical debt. Samples are given how a tool can be helpful in identifying and removing problems before they get out of hand. Also important is an external auditing agency which monitors projects in progress with the aide of automated tools. In the end a case study is presented which illustrates the monitoring of technical debt within an agile development and what counter measures are required to stop it.KeywordsTechnical debtcode qualityproduct documentationsoftware defectsrefactoringsoftware metricsagile team organizationagile testing

The practical implications of technical debt for the entire software life cycle; with examples and case studies. Technical debt in software is incurred when developers take shortcuts and make ill-advised technical decisions in the initial phases of a project, only to be confronted with the need for costly and labor-intensive workarounds later. This book offers advice on how to avoid technical debt, how to locate its sources, and how to remove it. It focuses on the practical implications of technical debt for the entire software lifecycle, with examples and case studies from companies that range from Boeing to Twitter. Technical debt is normal; it is part of most iterative development processes. But if debt is ignored, over time it may become unmanageably complex, requiring developers to spend all of their effort fixing bugs, with no time to add new features—and after all, new features are what customers really value. The authors explain how to monitor technical det, how to measure it, and how and when to pay it down. Broadening the conventional definition of technical debt, they cover requirements debt, implementation debt, testing debt, architecture debt, documentation debt, deployment debt, and social debt. They intersperse technical discussions with “Voice of the Practitioner” sidebars that detail real-world experiences with a variety of technical debt issues.

Due to cost and time constraints, software quality is often neglected in the evolution and adaptation of software. Thus, maintainability suffers, maintenance costs rise, and the development takes longer. These effects are referred to as “technical debt”. The challenge for project managers is to find a balance when using the given budget and schedule, either by reducing technical debt or by adding technical features. This balance is needed to keep time to market for current product releases short and future maintenance costs at an acceptable level. Method: The project ProDebt aimed at developing an innovative methodology and a software tool to support the strategic planning of technical debt in the context of agile software development. In this project, we created quality models and collected corresponding measurement data for two case studies in two different companies. Altogether, the two case studies contributed 5–6 years of data, from the end of 2011, resp. mid-2012, until today. Using measurement and effort data, we trained a machine-learning model to predict productivity based on measurement data—representing the technical debt of a file at a given point in time. Result: We developed a prototype and a prediction model for forecasting potential savings based on proposed refactorings of key drivers of technical debt identified by the model. In this paper, we present the approach and the experiences made during model development.

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

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

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

Technical Debt (TD) in software engineering refers to the additional cost generated by inadequate decisions or implementations in software projects. Requirements TD emerges when specific requirements are overlooked, poorly understood, or implemented inadequately, leading to disparities between the developed product and the original specifications. In this context, requirements engineering should worry about how to prevent requirements TD from occurring and how to deal with requirements TD. This paper presents a qualitative study investigating the causes of requirements TD and identifying actions that can mitigate or resolve them. This qualitative study occurs in a software project of a partnership between an IT company and the Computer Networks, Software Engineering, and Systems Group (GREat) of the Federal University of Ceará. The literature review helped identify types and causes of RTD, later correlated with responses from exploratory questions in project retrospective sessions. With the qualitative analysis conducted, significant challenges were detected, especially in the requirements elicitation phase, highlighting the need for more effective approaches. To deal with these issues, actions aimed at mitigating and resolving existing Requirements Technical Debts were identified and implemented.