Technical Debt Research Articles

Technical debt in the engineering of complex systems

AbstractThe metaphor of technical debt (TD) is widely adopted in the software engineering field, referring to short‐term compromises in software artifacts in exchange for speed or to meet release schedules or other constraints. The implication is that TDs accumulate over time, and may eventually make rework or maintenance very expensive or even impossible. The analogy is generally applicable in the systems engineering field, particularly concerning numerous program cancellation and obsolescence challenges due to premature decisions made in early acquisition phases. This paper adapts this metaphor of TD to the systems engineering field, and proposes a TD taxonomy to support the early identification and assessment of TD items in engineering complex systems, especially in the early life cycle phases of engineering complex, distributed systems. The taxonomy identifies seven TD types: functionality, performance, interoperability, version conflicts, documentation and support, system evolution, and organic, based on systematic indicators and signs discoverable during early acquisition activities. We expect that the notion and the taxonomy of TD will offer an additional perspective for design decisions that will help mitigate challenging integration and obsolescence issues in the engineering of complex systems.

Forecasting the Principal of Code Technical Debt in JavaScript Applications

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.

Managing Technical Debt Using Intelligent Techniques - A Systematic Mapping Study

Technical Debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefits but might hurt the long-term health of a software system. With the increasing amount of data generated when performing software development activities, an emergent research field has gained attention: applying Intelligent Techniques to solve Software Engineering problems. Intelligent Techniques were used to explore data for knowledge discovery, reasoning, learning, planning, perception, or supporting decision-making. Although these techniques can be promising, there is no structured understanding related to their application to support Technical Debt Management (TDM) activities. Within this context, this study aims to investigate to what extent the literature has proposed and evaluated solutions based on Intelligent Techniques to support TDM activities. To this end, we performed a Systematic Mapping Study (SMS) to investigate to what extent the literature has proposed and evaluated solutions based on Intelligent Techniques to support TDM activities. In total, 150 primary studies were identified and analyzed, dated from 2012 to 2021. The results indicated a growing interest in applying Intelligent Techniques to support TDM activities, the most used: Machine Learning and Reasoning under uncertainty. Intelligent Techniques aimed to assist mainly TDM activities related to identification, measurement, and monitoring. Design TD, Code TD, and Architectural TD are the TD types in the spotlight. Most studies were categorized at automation levels 1 and 2, meaning that existing approaches still require substantial human intervention. Symbolists and Analogizers are levels of explanation presented by most Intelligent Techniques, implying that these solutions conclude a general truth after considering a sufficient number of particular cases. Moreover, we also cataloged the empirical research types, contributions, and validation strategies described in primary studies. Based on our findings, we argue that there is still room to improve the use of Intelligent Techniques to support TDM activities. The open issues that emerged from this study can represent future opportunities for practitioners and researchers.

Self-Admitted Technical Debt in the Embedded Systems Industry: An Exploratory Case Study

Technical debt denotes shortcuts taken during software development, mostly for the sake of expedience. When such shortcuts are admitted explicitly by developers (e.g., writing a TODO/Fixme comment), they are termed as <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Self-Admitted Technical Debt</i> or <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">SATD</i> . There has been a fair amount of work studying SATD management in Open Source projects, but SATD in industry is relatively unexplored. At the same time, there is no work focusing on developers' perspectives towards SATD and its management. To address this, we conducted an exploratory case study in cooperation with an industrial partner to study how they think of SATD and how they manage it. Specifically, we collected data by identifying and characterizing SATD in different sources (issues, source code comments, and commits) and carried out a series of interviews with 12 software practitioners. The results show: 1) the core characteristics of SATD in industrial projects; 2) developers' attitudes towards identified SATD and statistics; 3) triggers for practitioners to introduce and repay SATD; 4) relations between SATD in different sources; 5) practices used to manage SATD; 6) challenges and tooling ideas for SATD management.

A modeling assistant to manage technical debt in coupled evolution

A modeling assistant to manage technical debt in coupled evolution

Self-admitted technical debt classification using natural language processing word embeddings

&lt;p&gt;Recent studies show that it is possible to detect technical dept automatically from source code comments intentionally created by developers, a phenomenon known as self-admitted technical debt. This study proposes a system by which a comment or commit is classified as one of five dept types, namely, requirement, design, defect, test, and documentation. In addition to the traditional term frequency-inverse document frequency (TF-IDF), several word embeddings methods produced by different pre-trained language models were used for feature extraction, such as Word2Vec, GolVe, bidirectional encoder representations from transformers (BERT), and FastText. The generated features were used to train a set of classifiers including naive Bayes (NB), random forest (RF), support vector machines (SVM), and two configurations of convolutional neural network (CNN). Two datasets were used to train and test the proposed systems. Our collected dataset (A-dataset) includes a total of 1,513 comments and commits manually labeled. Additionally, a dataset, consisting of 4,071 labeled comments, used in previous studies (M-dataset) was also used in this study. The RF classifier achieved an accuracy of 0.822 with A-dataset and 0.820 with the M-dataset. CNN with A-dataset achieved an accuracy of 0.838 using BERT features. With M-dataset, the CNN achieves an accuracy of 0.809 and 0.812 with BERT and Word2Vec, respectively.&lt;/p&gt;

How SonarQube-identified technical debt is prioritized: An exploratory case study

How SonarQube-identified technical debt is prioritized: An exploratory case study

Leveraging Lightning Web Components for Modern Salesforce UI Development

The evolution of Salesforce's user interface (UI) development has been marked by significant advancements, with Lightning Web Components (LWC) emerging as a pivotal technology. LWC represents a modern approach to building user interfaces on the Salesforce platform, enabling developers to create highly responsive, efficient, and scalable applications. This paper explores the significance of LWC in modern Salesforce UI development, highlighting its architectural advantages, performance improvements, and alignment with web standards. By leveraging LWC, developers can build applications that not only enhance the user experience but also streamline development processes, reduce technical debt, and ensure long-term maintainability. LWC is built on native web standards, such as Web Components, which allows developers to utilize reusable components across multiple applications. This modularity simplifies development, reduces redundancy, and promotes a cleaner, more maintainable codebase. Additionally, LWC's adherence to modern JavaScript frameworks and its compatibility with standard HTML and CSS make it an attractive choice for developers familiar with these technologies. This compatibility allows for seamless integration with other web development practices and tools, reducing the learning curve and accelerating the adoption of LWC in Salesforce projects. One of the critical advantages of LWC is its performance efficiency. Unlike its predecessor, Aura, LWC leverages native browser capabilities, resulting in faster load times and improved application responsiveness. The lightweight nature of LWC components ensures that applications can handle large volumes of data and complex user interactions without compromising performance. This efficiency is particularly crucial in enterprise environments where Salesforce applications must support thousands of users and handle significant data processing tasks. Moreover, LWC's design aligns with Salesforce's commitment to providing a robust, scalable, and secure platform. The framework includes built-in security features, such as Locker Service, which enforces security best practices by isolating components and preventing unauthorized access to sensitive data. This emphasis on security makes LWC an ideal choice for organizations that prioritize data protection and regulatory compliance. LWC also offers enhanced customization capabilities, enabling developers to tailor Salesforce applications to meet specific business requirements. Through LWC, developers can create custom user interfaces that integrate seamlessly with Salesforce's backend services and third-party APIs. This flexibility allows businesses to deliver unique, branded experiences to their users while maintaining the robustness and reliability of the Salesforce platform. The paper also delves into the ecosystem surrounding LWC, including the availability of pre-built components, tools, and resources that accelerate development. Salesforce provides an extensive library of base components that developers can leverage to quickly assemble complex UIs. Additionally, the Salesforce community and marketplace offer a wealth of third-party components and solutions, further expanding the possibilities for UI customization and enhancement. The adoption of LWC also fosters collaboration among development teams. Its modular architecture allows multiple developers to work on different components simultaneously, reducing bottlenecks and speeding up the development cycle. This collaborative approach is supported by Salesforce's developer tools, such as Salesforce CLI and Visual Studio Code extensions, which streamline the development, testing, and deployment of LWC-based applications. In conclusion, Lightning Web Components represent a significant leap forward in Salesforce UI development, offering a modern, efficient, and secure framework for building high-quality applications. By embracing LWC, organizations can enhance their Salesforce applications' user experience, improve performance, and future-proof their investments in the Salesforce platform. As businesses continue to demand more sophisticated and responsive applications, LWC will play a crucial role in meeting these expectations and driving innovation within the Salesforce ecosystem.

A practical approach for technical debt prioritization based on class‐level forecasting

AbstractMonitoring technical debt (TD) is considered highly important for software companies, as it provides valuable information on the effort required to repay TD and in turn maintain the system. When it comes to TD repayment, however, developers are often overwhelmed with a large volume of TD liabilities that they need to fix, rendering the procedure effort demanding. Hence, prioritizing TD liabilities is of utmost importance for effective TD repayment. Existing approaches rely on the current TD state of the system; however, prioritization would be more efficient by also considering its future evolution. To this end, the present work proposes a practical approach for prioritization of TD liabilities by incorporating information retrieved from TD forecasting techniques, emphasizing on the class‐level granularity to provide highly actionable results. Specifically, the proposed approach considers the change proneness and forecasted TD evolution of software artifacts and combines it with proper visualization techniques, to enable the early identification of classes that are more likely to become unmaintainable. To demonstrate and evaluate the approach, an empirical study is conducted on six real‐world applications. The proposed approach is expected to facilitate developers better plan refactoring activities, in order to manage TD promptly and avoid unforeseen situations long term.

Technical debt (TD) through the lens of Twitter: A survey

AbstractTechnical debt (TD) is a metaphor used to refer to the added software system costs acquired from taking shortcuts. Unfortunately, large amounts of TD can lead to serious consequences, and, thus, the management of TD is essential. Due to TD being a relatively new subject of study, many aspects of TD remain ambiguous. Fortunately, Twitter has been proven to hold a wealth of information on many subjects. As such, this survey study aims to gain a better understanding on how interest in TD has evolved over time and how TD is addressed on Twitter. A total of 128,897 TD‐related tweets were scrapped from Twitter and analyzed using a number of proxy measures and Latent Dirichlet Allocation (LDA). The results revealed that interest in TD on Twitter has been generally increasing since the platform's early stages. Furthermore, TD‐related tweets were found to revolve around 11 distinct categories. The TD in games category was discovered to be the most popular category, followed by TD communication and TD repayment. The results highlight that TD is a diverse and overarching topic that contains many potential avenues for further exploration. Software engineering researchers, practitioners, and educators can utilize this study to help steer their TD‐related future efforts.

Getting Trapped in Technical Debt: Sociotechnical Analysis of a Legacy System’s Replacement

Organizations replace their legacy systems for technical, economic, and operational reasons. Replacement is a risky proposition, as high levels of technical and social inertia make these systems hard to withdraw. Failure to fully replace systems results in complex system architectures involving manifold hidden dependencies that carry technical debt. To understand how a process for replacing a complex legacy system unfolds and accumulates technical debt, we conducted an explanatory case study at a local manufacturing site that had struggled to replace its mission-critical legacy systems as part of the larger global company’s commercial-off-the-shelf (COTS) system implementation. We approach the replacement as a sociotechnical change and leverage the punctuated sociotechnical information system change model in combination with the design-moves framework to analyze how the site balanced creating digital options, countering social inertia, and managing (architectural) technical debt. The findings generalize to a two-level (local/global) system-dynamics model delineating how replacing a deeply entrenched mission-critical system generates positive and negative feedback loops within and between social and technical changes at local and global levels. The loops, unless addressed, accrue technical debt that hinders legacy system discontinuance and gradually locks the organization into a debt-constrained state. The model helps managers anticipate challenges that accompany replacing highly entrenched systems and formulate effective strategies to address them.

Requirements on Technical Debt: Dare to Specify Them!

Could maintainability requirements help organizations prioritize technical debt management? The new standard ISO/IEC 5055 Automated Source Code Quality Measures can be used to set targets. We also look at a pragmatic way to turn CodeScene’s code health metric into a quality gate for pull requests.

Investigating the Relationship between Technical Debt Management and Software Development Issues

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.

What is asked about technical debt (TD) on Stack Exchange question-and-answer (Q&amp;A) websites? An observational study

What is asked about technical debt (TD) on Stack Exchange question-and-answer (Q&amp;A) websites? An observational study

Technical Debt Guild

Efficient Technical Debt Management (TDM) requires specialized guidance so that decisions taken are oriented to add value to the business. Because it is a complex problem that involves several variables, TDM requires a systemic look that considers professionals' experiences from different specialties. Guilds have been a means technology companies have united specialized professionals around a common interest, especially those using the Spotify methodology. This paper presents the experience of implementing a guild to support TDM's activities in a software development organization using the action research method. The project lasted three years, and approximately 120 developers were involved in updating about 63,300 source-code files, 2,314 test cases, 2,097 automated test scripts, and the build pipeline. The actions resulting from the TDM guild's efforts impacted the company's culture by introducing new software development practices and standards. Besides, they positively influenced the quality of the artifacts delivered by the developers. This study shows that, as the company acquires maturity in TDM, it increases the need for professionals dedicated to TDM's activities.

User as a source of the innovation based product value

Purpose: Development of the customer perceived value expression with the product use functions optimization model aiming particularly the case of new technology based innovations. Design/methodology/approach: Firstly, the role of customer is presented with particular attention payed to the client role in value creation process in the case of innovation based product. Then the perceived customer value and customer value definition are described. Those formulas are used in consequence as the base for expanded theoretic value concept, which is integrating the impact of used product brand and user functions mix. Finally, the introduced notion is developed in matrix form and briefly discussed. Findings: Extended formula of innovation based new product perceived customer value is presented in the form of the matrix notation, the possible application in the company innovation based product portfolio formation process is discussed. Research limitations/implications: Presented approach to the customer perceived value is based on the application of technical debt concept as the measure of analyzed product innovativeness, which is sensitive data and stay difficult to collect, particularly in case of new technologies. Practical implications: Proposed extended customer perceived value formula can be used as practical tool of new technology based innovative product, allowing to assess its market value in comparison to the existing company product cost structure. Makes possible to confront the customer product appreciation to those coming from the company interior analyzes. Hence its matrix form can serve as optimization model taking under consideration the possible market potential, impact of used brand and design and product use functions mix according to their technology life cycle. Social implications: Developed concept can reinforce the client role in commercialization process, particularly in case technology innovation. Also its use can be an interesting tool of prosumption development, making it more unambiguous and proactive. Originality/value: Presented extended formula of customer perceived vale can be applied as an interesting concept of research about nature the value of new technologies based innovation product also as base for practical managerial tool of optimization the new product mix during the commercialization process. Keywords: perceived innovativeness product value, new technology, technical debt. Category of the paper: Conceptual research paper.

Probabilistic Enhancement to the LEAP Process for Identifying Technical Debt in Iterative System Development

Probabilistic Enhancement to the LEAP Process for Identifying Technical Debt in Iterative System Development

Predicting the Dynamics of Earned Value Creation in the Presence of Technical Debt

Predicting the Dynamics of Earned Value Creation in the Presence of Technical Debt

Qualitative Clustering of Software Repositories Based on Software Metrics

Software repositories contain a wealth of information about the aspects related to software development process. For this reason, many studies analyze software repositories using methods of data analytics with a focus on clustering. Software repository clustering has been applied in studying software ecosystems such as GitHub, defect and technical debt prediction, software remodularization. Although some interesting insights have been reported, the considered studies exhibited some limitations. The limitations are associated with the use of individual clustering methods and manifesting in the shortcomings of the obtained results. In this study, to alleviate the existing limitations we engage multiple cluster validity indices applied to multiple clustering methods and carry out consensus clustering. To our knowledge, this study is the first to apply the consensus clustering approach to analyze software repositories and one of the few to apply the consensus clustering to software metrics. Intensive experimental studies are reported for software repository metrics data consisting of a number of software repositories each described by software metrics.We revealed seven clusters of software repositories and relate them to developers’ activity. It is advocated that the proposed clustering environment could be useful for facilitating the decision making process for business investors and open-source community with the help of the Gartner’s hype cycle.

Ontology for Technical Debt in Systems Engineering

Ontology for Technical Debt in Systems Engineering