Technical Debt Research Articles

A Critical Comparison on Six Static Analysis Tools: Detection Agreement and Precision

Background. Developers use Automated Static Analysis Tools (ASATs) to control for potential quality issues in source code, including defects and technical debt. Tool vendors have devised quite a number of tools, which makes it harder for practitioners to select the most suitable one for their needs. To better support developers, researchers have been conducting several studies on ASATs to favor the understanding of their actual capabilities. Aims. Despite the work done so far, there is still a lack of knowledge regarding (1) which source quality problems can actually be detected by static analysis tool warnings, (2) what is their agreement, and (3) what is the precision of their recommendations. We aim at bridging this gap by proposing a large-scale comparison of six popular static analysis tools for Java projects: Better Code Hub, CheckStyle, Coverity Scan, Findbugs, PMD, and SonarQube. Method. We analyze 47 Java projects and derive a taxonomy of warnings raised by 6 state-of-the-practice ASATs. To assess their agreement, we compared them by manually analyzing - at line-level - whether they identify the same issues. Finally, we manually evaluate the precision of the tools. Results. The key results report a comprehensive taxonomy of ASATs warnings, show little to no agreement among the tools and a low degree of precision. Conclusions. We provide a taxonomy that can be useful to researchers, practitioners, and tool vendors to map the current capabilities of the tools. Furthermore, our study provides the first overview on the agreement among different tools as well as an extensive analysis of their precision.

ANÁLISE QUANTITATIVA DA AQUISIÇÃO DE DÍVIDA TÉCNICA EM SISTEMAS LEGADOS

Software development companies that work with legacy systems face challenges typical of these systems, e.g. , main- tenance carried out for decades, outdated concepts, and a system heavily coupled with the hardware. Conversely, tech- nical debt describes the development of low-quality systems to be delivered quickly but with the view that the system will be improved in the future. Such situations occur when the delivery of a module has to be fast to meet market de- mand. Thus, legacy systems and technical debt are firmly linked, as the maintenance that occurs in the former are, in most cases, technical adjustments to modernize the system, both in terms of requirements and technology. The mana- gement of technical debts and legacy systems is a challenge. Therefore, this work aims to identify the factors of technical debt acquisition in legacy software in the Western Region of Santa Catarina, according to classification patterns already identified in the literature. The research followed an applied approach, from identifying characteristics of companies in the area and the relationship with their programming prac- tices and prioritization of corrections. The results confirmed the presence of factors already described in the literature, such as process, attitude, pragmatism, and prioritization, present in the development of the researched products. Ne- vertheless, there was no significant relationship between the characteristics of the companies and the acquisition of tech- nical debts.

Self-Admitted Technical Debt in Commit Messages: Comparing Java, Python, and R

Self-Admitted Technical Debt in Commit Messages: Comparing Java, Python, and R

The Lifecycle of Technical Debt that Manifest in Both Source Code and Issue Trackers

The Lifecycle of Technical Debt that Manifest in Both Source Code and Issue Trackers

Characteristics, Causes, and Consequences of Technical Debt in the Automation Domain

Characteristics, Causes, and Consequences of Technical Debt in the Automation Domain

The Impact of Peer Code Review on Software Maintainability in Open-Source Software: A Case Study

Recently, open-source software (OSS) has become a considerably popular and reliable source of functionality corrections. OSS also allows software developers to reduce technical debt in software development. However, previous studies have shown that the main problem within OSS development is the lack of systematic processes and formal documents related to system development, such as requirements, designs, and testing. This feature of OSS development causes problems in the software quality, such as those related to security and maintainability. In this research, the authors focused on the software’s maintainability because this attribute has to greatest potential to reduce the cost and increase the productivity of the software development process. There is currently no existing research that examines whether OSS developers pay attention to software maintainability. To better understand how OSS developers improve software maintainability, this research aims to answer the question: “Are developers interested in software maintainability under the modern code review of open-source software projects?” To answer the research question, the authors investigated the code review process in which the OSS developers changed the code based on a review of code comments related to maintenance and collected the sub-characteristics associated with software maintainability from the existing literature. The authors examined the review comments from two OSS projects: Eclipse and Qt. The results suggest that the number of code revisions due to maintenance issues was moderate and that the OSS developers tend to improve source code quality. This direction could be observed from the increasing number of modifications on given maintenance-based comments over the years. Therefore, an implication of this is the possibility that OSS project developers are interested in software maintainability.

Accumulation and Prioritization of Architectural Debt in Three Companies Migrating to Microservices

Many companies migrate to microservices because they help deliver value to customers quickly and continuously. However, like any architectural style, microservices are prone to architectural technical debt (ATD), which can be costly if the debts are not timely identified, avoided, or removed. During the early stages of migration, microservice-specific ATDs (MS-ATDs) may accumulate. For example, practitioners may decide to continue using poorly defined APIs in microservices while attempting to maintain compatibility with old functionalities. The riskiest MS-ATDs must be prioritized. Nevertheless, there is limited research regarding the prioritization of MS-ATDs in companies migrating to microservices. This study aims to identify, during migration, which MS-ATDs occur, are the most severe, and are the most challenging to solve. In addition, we propose a way to prioritize these debts. We conducted a multiple exploratory case study of three large companies that were early in the migration process to microservices. We interviewed 47 practitioners with several roles to identify the debts in their contexts. We report the MS-ATDs detected during migration, the MS-ATDs that practitioners estimate to occur in the future, and the MS-ATDs that practitioners report as difficult to solve. We discuss the results in the context of the companies involved in this study. In addition, we used a risk assessment approach to propose a way for prioritizing MS-ATDs. Practitioners from other organizations and researchers may use this approach to provide rankings to help identify and prioritize which MS-ATDs should be avoided or solved in their contexts.

Transportation Makes Modern Retail “Click”: Research Questions for the Future

Abstract The modern retail environment is evolving rapidly under the confluence of technological advancement, environmental uncertainty, and general market dynamism. We summarize and synthesize the studies in this special-topic issue to illustrate how transportation capabilities enable members of the modern retail supply chain to adopt new business models, enhance lifestyles of community members, and contribute to corporate social responsibility. Further, we propose extensions to the studies published in this issue to further examine the future of transportation in retail. Notably, we call for future studies to explore how retail supply chain members may (1) develop new transportation and distribution capabilities by overcoming technical debt associated with specialized but abandoned assets; (2) leverage secondary markets to develop a closed-loop supply chain to maximize value and minimize waste; and (3) use enhanced transportation transparency and visibility to enhance customer service and sustainability efforts in retail supply chains.

Problem identification and intervention in the higher education data synchronization system in Indonesia

IT Department identified problems in reporting student study activities (AKM) by interviewing stakeholders. Then the priorities of the problems are ineffective business process and technical matters determined by using Pareto Analysis. This study proposed two solutions, application of data governance to achieve an effective business process and application of metadata management to solve the technical matters. Both solutions were socialized, tested and applied among all stakeholders. The result was that the percentage of AKM completeness increased significantly from 84% to 100% and Data Reporting Team now can send data faster and reduce data transmission errors which decrease technical debt problem.

A reference architecture for the operationalization of machine learning models in manufacturing

Inherent characteristics of machine learning algorithms such as their probabilistic nature, their reliance on large datasets as well as their need for constant retraining pose major challenges to the operationalization of machine learning models (MLOps) in the manufacturing domain. As such systems are known to quickly accumulate technical debt due to system-level interdependencies of code, data, and models, clear abstractions boundaries are mandatory. Therefore, this publication derives a systematic functional decomposition of an MLOps system tailored to the manufacturing industry into specific domains and contexts. Moreover, a concrete deployment view is provided, and possible future research directions are discussed.

A Transformational Approach to Managing Data Model Evolution of Web Services

The communication of web services is typically organized through APIs, which rely on a common data model shared among system components. Over time, this data model must be changed in order to accommodate new or changing requirements, and the components including the data they are operating on must be migrated. In practice however, not all affected components can be migrated instantly and at the same time. A common approach is to plan data model changes in a backward compatible fashion, which causes serious maintenance problems and is a common cause of technical debt. We propose an alternative solution, using a translation layer serving as a round-trip migration service, responsible for the lossless translation of object-oriented data model instances of different versions. We present a framework which offers a version-aware interface definition language (IDL) for APIs, a typed JavaScript-based language using the IDL definition, and a run-time environment. From a methodological point of view, development is supported by a catalog which comprises a set of typical evolution scenarios along with corresponding round-trip migration strategies. We showcase the applicability of our approach via a case study of a real-world e-commerce web application, and evaluate correctness through automated testing.

An Empirical Study of the Extent and Causes of Technical Debt in Public Organizations Software Systems

An Empirical Study of the Extent and Causes of Technical Debt in Public Organizations Software Systems

Empirical Research for Self-Admitted Technical Debt Detection in Blockchain Software Projects

Empirical Research for Self-Admitted Technical Debt Detection in Blockchain Software Projects

A Taxonomy of Assets for the Development of Software-Intensive Products and Services

Context: Developing software-intensive products or services involves utilising many artefacts that are either part of the offering or part of enabling their development. These artefacts, if valuable and used more than once by the development organisation, can be seen as assets such as test cases, code, requirements, and documentation. As such, assets are often reused, updated, and become a base or even necessity for product development and evolution over time, constituting an investment. Assets are not well understood beyond code-based ones in the area of technical debt. Thus most asset types are often overlooked, and their state, which is subject to degradation over time, has not been much studied. Method: To address the problem, we conducted industrial focus groups with five companies and a literature review. The results were analysed qualitatively and summarised in a taxonomy. Results: We created a structured, extendable taxonomy of assets. The taxonomy contains 57 assets. Conclusions: The taxonomy serves as foundations for defining and identifying assets as a concept. It provides the foundation for studies into asset degradation and subsequent asset management. The taxonomy also includes code-based assets and thus can be helpful in further research into investigating degradation and debt concepts.

On the documentation of refactoring types

Commit messages are the atomic level of software documentation. They provide a natural language description of the code change and its purpose. Messages are critical for software maintenance and program comprehension. Unlike documenting feature updates and bug fixes, little is known about how developers document their refactoring activities. Specifically, developers can perform multiple refactoring operations, including moving methods, extracting classes, renaming attributes, for various reasons, such as improving software quality, managing technical debt, and removing defects. Yet, there is no systematic study that analyzes the extent to which the documentation of refactoring accurately describes the refactoring operations performed at the source code level. Therefore, this paper challenges the ability of refactoring documentation, written in commit messages, to adequately predict the refactoring types, performed at the commit level. Our analysis relies on the text mining of commit messages to extract the corresponding features (i.e., keywords) that better represent each class (i.e., refactoring type). The extraction of text patterns, specific to each refactoring type (e.g., rename, extract, move, inline, etc.) allows the design of a model that verifies the consistency of these patterns with their corresponding refactoring. Such verification process can be achieved via automatically predicting, for a given commit, the method-level type of refactoring being applied, namely Extract Method, Inline Method, Move Method, Pull-up Method, Push-down Method, and Rename Method. We compared various classifiers, and a baseline keyword-based approach, in terms of their prediction performance, using a dataset of 5004 commits. Our main findings show that the complexity of refactoring type prediction varies from one type to another. Rename Method and Extract Method were found to be the best documented refactoring activities, while Pull-up Method, and Push-down Method were the hardest to be identified via textual descriptions. Such findings bring the attention of developers to the necessity of paying more attention to the documentation of these types.

Driving Efficiency and Innovation: The Impact of Low - Code BPM Tools on Technical Debt Reduction

Driving Efficiency and Innovation: The Impact of Low - Code BPM Tools on Technical Debt Reduction

Technical debt payment and prevention through the lenses of software architects

Architectural decisions are considered one of the most common sources of technical debt (TD). Thus, it is necessary to understand how TD is perceived by software architects, particularly, the practices supporting the elimination of debt items from projects, and the practices used to reduce the chances of TD occurrence. This paper investigates the most commonly used practices to pay off TD and to prevent debt occurrence in software projects from the architect’s point of view. We used the available data from InsighTD, which is a globally distributed family of industrial surveys on the causes, effects, and management of TD. We analyze responses from a corpus of 72 software architects from Brazil, Chile, Colombia, and the United States. Results showed that refactoring (30.2%) was the main practice related to TD payment, followed by design improvements (14.0%). Refactoring, design improvements, and test improvements are the most cited payment practices among cases of code, design and test debt. Concerning the TD preventive practices, we find that having a well-defined architecture and design is the most cited practice (13.6%), followed by having a well-defined scope and requirements. This last practice is the most cited one for expert software architects. Finally, when comparing preventive practices among the three major roles derived from the survey (software architects, engineer roles, and management roles), we found that none of the roles shared the most cited practice, meaning that each role had its worries and focus on different strategies to reduce TD’s presence in the software. The lists of TD payment and prevention practices can guide software teams by having a catalog of practices to keep debt controlled or reduced.

Technical debt resulting from architectural degradation and code smells

Poor design choices, bad coding practices, or the need to produce software quickly can stand behind technical debt. Unfortunately, manually identifying and managing technical debt gets more difficult as the software matures. Recent research offers various techniques to automate the process of detecting and managing technical debt to address these challenges. This manuscript presents a mapping study of the many aspects of technical debt that have been discovered in this field of study. This includes looking at the various forms of technical debt, as well as detection methods, the financial implications, and mitigation strategies. The findings and outcomes of this study are applicable to a wide range of software development life-cycle decisions.

Reproducibility in the technical debt domain

Abstract Context It is crucial to understand how reproducible the measurement results in the scientific publications are, as reproducibility is one of the cornerstones of engineering. Objective The goal of this study is to investigate the scientific publications presented at the premier technical debt conferences by understanding how reproducible the reported findings are. Method We conducted a systematic literature review of 135 unique papers published at the “International Workshop on Managing Technical Debt” and the “International Conference on Managing Technical Debt”, the premier scientific conference series on technical debt. Results Only 44 of the investigated 135 papers presented numerical evidence and only 5 papers listed the tools, the availability of the tools, and the version of the tools used. For the rest of the papers additional information would have been needed for the potential reproducibility. One of the published papers even referred to a pornographic site as a source of a toolset for empirical research.

Algorithmic Silence: A Call to Decomputerize

Tech critics become technocrats when they overlook the daunting administrative density of a digital-first society. The author implores critics to reject structural dependencies on digital tools rather than naturalize their integration through critique and reform. At stake is the degree to which citizens must defer to unelected experts to navigate such density. Democracy dies in the darkness of sysadmin. The argument and a candidate solution proceed as follows. Since entropy is intrinsic to all physical systems, including digital systems, perfect automation is a fiction. Concealing this fiction, however, are five historical forces usually treated in isolation: ghost work, technical debt, intellectual debt, the labor of algorithmic critique, and various types of participatory labor. The author connects these topics to emphasize the systemic impositions of digital decision tools, which compound entangled genealogies of oppression and temporal attrition. In search of a harmonious balance between the use of “AI” tools and the non-digital decision systems they are meant to supplant, the author draws inspiration from an unexpected source: musical notation. Just as musical notes require silence to be operative, the author positions algorithmic silence-the deliberate exclusion of highly abstract digital decision systems from human decision-making environments-as a strategic corrective to the fiction of total automation. Facial recognition bans and the Right to Disconnect are recent examples of algorithmic silence as an active trend.