Technical Debt Research Articles

DebtCom: Technical Debt-Aware Service Recomposition in SaaS Cloud

Given the changing workloads from the tenants, it is not uncommon for a service composition running in the multi-tenant SaaS cloud to encounter under-utilization and over-utilization on the component services. Both cases are undesirable and it is therefore nature to mitigate them by recomposing the services to a newly optimized composition plan once they have been detected. However, this ignores the fact that under-/over-utilization can be merely caused by temporary effects, and thus the advantages may be short-term, which hinders the long-term benefits that could have been created by the original composition plan, while generating unnecessary overhead and disturbance via recomposition. In this paper, we propose <monospace xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">DebtCom</monospace> , a framework that determines whether to trigger recomposition based on the technical debt metaphor and time-series prediction of workload. In particular, we propose a service debt model, which has been explicitly designed for the context of service composition, to quantify the debt. Our core idea is that recomposition can be unnecessary if the under-/over-utilization only cause temporarily negative effects, and the current composition plan, although carries debt, can generate greater benefit in the long-term. We evaluate <monospace xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">DebtCom</monospace> on a large scale service system with up to 10 abstract services, each of which has 100 component services, under real-world dataset and workload traces. The results confirm that, in contrast to the state-of-the-art, <monospace xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">DebtCom</monospace> achieves better utility while having lower cost and number of recompositions, rendering each composition plan more sustainable.

Deep Learning-Based Self-Admitted Technical Debt Detection Empirical Research

&lt;p&gt;Self-Admitted Technical Debt (SATD) is a workaround for current gains and subsequent software quality in software comments. Some studies have been conducted using NLP-based techniques or CNN-based classifiers. However, there exists a class imbalance problem in different software projects since the software code comments with SATD features are significantly less than those without Non-SATD. Therefore, to design a classification model with the ability of dealing with this class imbalance problem is necessary for SATD detection. We propose an improved loss function based on information entropy. Our proposed function is studied in a variety of application scenarios. Empirical research on 10 JAVA software projects is conducted to show the competitiveness of our new approach. We find our proposed approach can perform significantly better than state-of-the-art baselines. &lt;/p&gt; &lt;p&gt;&amp;nbsp;&lt;/p&gt;

The lifecycle of Technical Debt that manifests in both source code and issue trackers

The lifecycle of Technical Debt that manifests in both source code and issue trackers

Investigation on Self-Admitted Technical Debt in Open-Source Blockchain Projects

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.

A catalogue of game-specific anti-patterns based on GitHub and Game Development Stack Exchange

With the ever-increasing use of games, game developers are expected to write efficient code and support several aspects such as security, maintainability, and performance. However, the need for frequent updates in game development may lead to quick-fix solutions and bad coding practices. Though unintentional, these bad practices may lead to poor program comprehension and can cause several issues during software maintenance. The quick-fix solutions might lead to technical debts due to the presence of anti-patterns and code smells, which may affect the functional and non-functional requirements of the game. To avoid such instances, game developers may need some guidelines to refer to during the game development process. Thus, to aid developers and researchers, in our previous work, we had presented an initial catalogue of anti-patterns in the domain of game development. To broaden the scope of the catalogue and diversify the instances of anti-patterns, we analyzed additional data from a Q&A platform. We present 15 game-specific anti-patterns based on thematic analysis of 189 issues, 892 commits, 104 pull requests from 100 open-source GitHub game repositories, and 971 questions from Game Development Stack Exchange. We see the catalogue as an effort towards improving the development and quality of the games. The catalogue containing a detailed description of every anti-pattern with the context, problem, solution, example(s), and their occurrences on GitHub and Game Development Stack Exchange is available at https://rishalab.github.io/Catalog-of-Game-Antipatterns/.

DESIGN METHODS FOR DIAGNOSING AND LOCATING ENTANGLED TECHNICAL DEBT IN DEVOPS FRAMEWORKS

AbstractIn the IT landscape, DevOps is the preferred approach for developing and maintaining rapidly evolving systems that require continuous improvements. Yet, DevOps frameworks do not entirely prevent the accumulation of Technical Debt (TD), and under certain circumstances DevOps can even contribute to generating TD. This paper focuses on a specific type of TD, Entangled Technical Debt (ETD), that corresponds to the implicit complexification of a system's design and the appearance of unintentional couplings in its architecture over time. Our work seeks to inform methods for Diagnosing and Locating ETD in DevOps frameworks. Through a research partnership with Ubisoft's IT branch, an experimental case-study was conducted. It takes the form of an assessment of 6 innovative IT projects and a subsequent in-depth architecture analysis of an individual IT system, which enabled the characterization of the mechanisms linking DevOps to ETD. This allowed us to develop and test practical methods for diagnosing and locating ETD in IT systems.

Systematic review of data-centric approaches in artificial intelligence and machine learning

Artificial intelligence (AI) relies on data and algorithms. State-of-the-art (SOTA) AI smart algorithms have been developed to improve the performance of AI-oriented structures. However, model-centric approaches are limited by the absence of high-quality data. Data-centric AI is an emerging approach for solving machine learning (ML) problems. It is a collection of various data manipulation techniques that allow ML practitioners to systematically improve the quality of the data used in an ML pipeline. However, data-centric AI approaches are not well documented. Researchers have conducted various experiments without a clear set of guidelines. This survey highlights six major data-centric AI aspects that researchers are already using to intentionally or unintentionally improve the quality of AI systems. These include big data quality assessment, data preprocessing, transfer learning, semi-supervised learning, machine ​learning ​operations (MLOps), and the effect of adding more data. In addition, it highlights recent data-centric techniques adopted by ML practitioners. We addressed how adding data might harm datasets and how HoloClean can be used to restore and clean them. Finally, we discuss the causes of technical debt in AI. Technical debt builds up when software design and implementation decisions run into “or outright collide with” business goals and timelines. This survey lays the groundwork for future data-centric AI discussions by summarizing various data-centric approaches.

Detecting multi-type self-admitted technical debt with generative adversarial network-based neural networks

Detecting multi-type self-admitted technical debt with generative adversarial network-based neural networks

Characteristics, causes, and consequences of technical debt in the automation domain

Technical Debt (TD) is a significant concern in software development, particularly when interdisciplinary teams collaborate and interact. The goal of the study is to investigate TD causal chains and patterns in the industrial automation sector by analyzing 123 mechatronic TD incidents from 47 expert interviews across ten companies. Findings reveal that Requirements, Process, and Test TD are most common, while Build, Versioning, Manufacturing, Code, and Maintenance/Service TD are less frequent. Key causes include ”other priorities”, ”lack of time”, ”historically grown products”, ”lack of market analysis” and ”copy-paste-modify without revising tolerances.” The research identifies correlations between TD subtypes and causes/consequences in relation to company size, experts’ experience, and position, utilizing the Chi-square test and PrefixSpan algorithm. The study also maps the contagious character of TD using Neo4J graphical representation. This first in-depth analysis of TD causal chains in industrial automation contributes qualitatively to understanding TD patterns, helping researchers and practitioners assess TD contagiousness, comprehend its effects, prevent diffusion, and develop repayment strategies To the best of our knowledge, this study’s quantitative analysis approach provides the foundation that will enable future research identifying TD metrics and TD management in multidisciplinary engineering.

Rubbing salt in the wound? A large-scale investigation into the effects of refactoring on security

Software refactoring is a behavior-preserving activity to improve the source code quality without changing its external behavior. Unfortunately, it is often a manual and error-prone task that may induce regressions in the source code. Researchers have provided initial compelling evidence of the relation between refactoring and defects, yet little is known about how much it may impact software security. This paper bridges this knowledge gap by presenting a large-scale empirical investigation into the effects of refactoring on the security profile of applications. We conduct a three-level mining software repository study to establish the impact of 14 refactoring types on (i) security-related metrics, (ii) security technical debt, and (iii) the introduction of known vulnerabilities. The study covers 39 projects and a total amount of 7,708 refactoring commits. The key results show that refactoring has a limited connection to security. However, Inline Method and Extract Interface statistically contribute to improving some security aspects connected to encapsulating security-critical code components. Extract Superclass and Pull Up Attribute refactoring are commonly found in commits violating specific security best practices for writing secure code. Finally, Extract Superclass and Extract & Move Method refactoring tend to occur more often in commits contributing to the introduction of vulnerabilities. We conclude by distilling lessons learned and recommendations for researchers and practitioners.

A Software Vulnerability Management Framework for the Minimization of System Attack Surface and Risk

Current Internet of Things (IoT) systems comprise multiple software systems that are deployed to provide users with the required functionalities. System architects create system blueprints and draw specifications for the software artefacts that are needed; subsequently, either custom-made software is developed according to these specifications and/or ready-made COTS/open source software may be identified and customized to realize the overall system goals. All deployed software however may entail vulnerabilities, either due to insecure coding practices or owing to misconfigurations and unexpected interactions. Moreover, software artefacts may implement a much broader set of functionalities than may be strictly necessary for the system at hand, in order to serve a wider range of needs, and failure to appropriately configure the deployed software to include only the required modules results in the further increase of the system attack surface and the associated risk. In this paper, we present a software vulnerability management framework which facilitates (a) the configuration of software to include only the necessary features, (b) the execution of security-related tests and the compilation of platform-wide software vulnerability lists, and (c) the prioritization of vulnerability addressing, considering the impact of each vulnerability, the associated technical debt for its remediation, and the available security budget. The proposed framework can be used as an aid in IoT platform implementation by software architects, developers, and security experts.

TD Pulse: Assessing the Systematic Management of Technical Debt

Technical Debt requires the management of several technical and non-technical aspects: process, organization, tools, etc. Software companies must identify where TD is not well managed and where to improve. Based on ten years of research and practice, we have created an effective approach, TD Pulse, to assess Technical Debt Management in large software companies and find critical improvement areas. The approach was used by 232 and evaluated by more than 200 practitioners in three large companies, including Siemens and Zenseact. The results show that our approach is valuable and lightweight. We also share lessons learned from the whole assessment experience.

Defining, Measuring, and Managing Technical Debt

Ward Cunningham introduced the metaphor underlying the term technical debt in a 1992 experience report, where he described how his company incrementally extended a piece of financial software:

The FastLanes Compression Layout: Decoding &gt; 100 Billion Integers per Second with Scalar Code

The open-source FastLanes project aims to improve big data formats, such as Parquet, ORC and columnar database formats, in multiple ways. In this paper, we significantly accelerate decoding of all common Light-Weight Compression (LWC) schemes: DICT, FOR, DELTA and RLE through better data-parallelism. We do so by re-designing the compression layout using two main ideas: (i) generalizing the value interleaving technique in the basic operation of bit-(un)packing by targeting a virtual 1024-bits SIMD register, (ii) reordering the tuples in all columns of a table in the same Unified Transposed Layout that puts tuple chunks in a common "04261537" order (explained in the paper); allowing for maximum independent work for all possible basic SIMD lane widths: 8, 16, 32, and 64 bits. We address the software development, maintenance and future-proofness challenges of increasing hardware diversity, by defining a virtual 1024-bits instruction set that consists of simple operators supported by all SIMD dialects; and also, importantly, by scalar code. The interleaved and tuple-reordered layout actually makes scalar decoding faster, extracting more data-parallelism from today's wide-issue CPUs. Importantly, the scalar version can be fully auto-vectorized by modern compilers, eliminating technical debt in software caused by platform-specific SIMD intrinsics. Micro-benchmarks on Intel, AMD, Apple and AWS CPUs show that FastLanes accelerates decoding by factors (decoding &gt;40 values per CPU cycle). FastLanes can make queries faster, as compressing the data reduces bandwidth needs, while decoding is almost free.

Refactoring in Computational Notebooks

Due to the exploratory nature of computational notebook development, a notebook can be extensively evolved even though it is small, potentially incurring substantial technical debt. Indeed, in interview studies notebook authors have attested to performing ongoing tidying and big cleanups. However, many notebook authors are not trained as software developers, and environments like JupyterLab possess few features to aid notebook maintenance. As software refactoring is traditionally a critical tool for reducing technical debt, we sought to better understand the unique and growing ecology of computational notebooks by investigating the refactoring of public Jupyter notebooks. We randomly selected 15,000 Jupyter notebooks hosted on GitHub and studied 200 with meaningful commit histories. We found that notebook authors do refactor, favoring a few basic classic refactorings as well as those involving the notebook cell construct. Those with a computing background refactored differently than others, but not more so. Exploration-focused notebooks had a unique refactoring profile compared to more exposition-focused notebooks. Authors more often refactored their code as they went along, rather than deferring maintenance to big cleanups. These findings point to refactoring being intrinsic to notebook development.

An Agile Model-Based Software Engineering Approach Illustrated through the Development of a Health Technology System

Model-Based Software Engineering (MBSE) is an architecture-based software development approach. Agile, on the other hand, is a light system development approach that originated in software development. To bring together the benefits of both approaches, this article proposes an integrated Agile MBSE approach that adopts a specific instance of the Agile approach (i.e., Scrum) in combination with a specific instance of an MBSE approach (i.e., Model-Based System Architecture Process—“MBSAP”) to create an Agile MBSE approach called the integrated Scrum Model-Based System Architecture Process (sMBSAP). The proposed approach was validated through a pilot study that developed a health technology system over one year, successfully producing the desired software product. This work focuses on determining whether the proposed sMBSAP approach can deliver the desired Product Increments with the support of an MBSE process. The interaction of the Product Development Team with the MBSE tool, the generation of the system model, and the delivery of the Product Increments were observed. The preliminary results showed that the proposed approach contributed to achieving the desired system development outcomes and, at the same time, generated complete system architecture artifacts that would not have been developed if Agile had been used alone. Therefore, the main contribution of this research lies in introducing a practical and operational method for merging Agile and MBSE. In parallel, the results suggest that sMBSAP is a middle ground that is more aligned with federal and state regulations, as it addresses the technical debt concerns. Future work will analyze the results of a quasi-experiment on this approach focused on measuring system development performance through common metrics.

Automatic identification of self-admitted technical debt from four different sources

Technical debt refers to taking shortcuts to achieve short-term goals while sacrificing the long-term maintainability and evolvability of software systems. A large part of technical debt is explicitly reported by the developers themselves; this is commonly referred to as Self-Admitted Technical Debt or SATD. Previous work has focused on identifying SATD from source code comments and issue trackers. However, there are no approaches available for automatically identifying SATD from other sources such as commit messages and pull requests, or by combining multiple sources. Therefore, we propose and evaluate an approach for automated SATD identification that integrates four sources: source code comments, commit messages, pull requests, and issue tracking systems. Our findings show that our approach outperforms baseline approaches and achieves an average F1-score of 0.611 when detecting four types of SATD (i.e., code/design debt, requirement debt, documentation debt, and test debt) from the four aforementioned sources. Thereafter, we analyze 23.6M code comments, 1.3M commit messages, 3.7M issue sections, and 1.7M pull request sections to characterize SATD in 103 open-source projects. Furthermore, we investigate the SATD keywords and relations between SATD in different sources. The findings indicate, among others, that: 1) SATD is evenly spread among all sources; 2) issues and pull requests are the two most similar sources regarding the number of shared SATD keywords, followed by commit messages, and then followed by code comments; 3) there are four kinds of relations between SATD items in the different sources.

IT managers’ perspective on Technical Debt Management

Context:Technical Debt (TD) is a term for software solutions that are beneficial in the short-term but impede future change. Goal:Previous research on TD indicates various management-related causes. We analyze the perspective of IT managers on TD since they usually have a major influence on deadlines, the project’s budget, and setting up a TD management (TDM) process. Method:To determine the IT managers’ perspective, we obtained and analyzed data from 16 semi-structured interviews and a three-person focus group discussion. Results:We found that all IT managers understood the TD concept. They consider TDM to be an essential topic, though nearly none of them had set up a TDM process so far. We identified three major concerns the IT managers had regarding TDM: communicating about TD, establishing a TDM process, and dealing with vintage systems, i.e., old legacy systems We developed a model specifying causes and consequences visible to business stakeholders, causal chains, and vicious cycles. Conclusions:Our research identifies new research gaps and demonstrates to practitioners that investing in a TDM process may be beneficial. It provides the V4CTD model of Visibility, Cycles & Chains of Causes & Consequences of TD, extending the TD conceptual model and facilitating communication on TD with business stakeholders.Editor’s note: Open Science material was validated by the Journal of Systems and Software Open Science Board.

Technical debt in systems engineering—A systematic literature review

AbstractThe metaphor of “technical debt” is used in software engineering to describe technical solutions that may be pragmatic in the near‐term but may have a negative long‐term impact. Similar decisions and similar dynamics are present in the field of systems engineering. This work investigates the current body of knowledge to identify if, and how, the technical debt metaphor is used within the systems engineering field and which systems engineering lifecycle stages are most susceptible to technical debt. A systematic literature review was conducted on 354 papers in February 2022, of which 18 were deemed relevant for inclusion in the study. The results of the systematic literature review show that the technical debt metaphor is not prevalent within systems engineering research and that existing research is limited to specific fields and theoretical discussions. This paper concludes with recommendations for future work to establish a research agenda on the identification and management of technical debt within systems engineering.

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.