Search

Self-Admitted Technical Debt (SATD) is a form of Technical Debt where developers document the debt using source code comments(SATD-C)or issues (SATD-I). However, it is still unclear the circumstances that drivedevelopers to choose one or another. In this paper,we survey authors of both types of debts using a large-scale dataset containing 74K SATD-C and 20K SATD-I instances, extracted from190 GitHub projects. As a result, we provide 13 guidelines to support developers to decide when to use comments or issues to reportTechnical Debt.

Architectural Technical Debt (ATD) is considered as the most significant type of TD in industrial practice. In this study, we interview 21 software engineers and architects to investigate a specific type of ATD, namely architectural smells (AS). Our goal is to understand the phenomenon of AS better and support practitioners to better manage it and researchers to offer relevant support. The findings of this study provide insights on how practitioners perceive AS and how they introduce them, the maintenance and evolution issues they experienced and associated to the presence of AS, and what practices and tools they adopt to manage AS., Submitted and accepted to IEEE Software special issue on Technical Debt. This is a preprint

This article presents technical debt (TD) impediments, decision factors, enabling practices, and actions diagrams for TD management in agile software projects. By analyzing diagrams, professionals can avoid the pitfalls, and increase their capacity, for better TD management.

Delivering increasingly complex software-reliant systems demands better ways to manage the long-term effects of short-term expedients. The technical debt (TD) metaphor has gained significant traction as a way to understand and communicate such issues. Almost 25 years after the term was coined in 1992 by Ward Cunningham, and more than 10 years after the first edition of the TechDebt workshop/conference series, we take a brief look at the past, present, and future of TD.

A fundamental problem and an open challenge is managing technical debt in the presence of uncertainty. We provide an overview of the research, practical limitations, and future study of the current state of technical debt management under uncertainty.

Technical debt analysis of procedural languages has not kept up with the growth in popularity of procedural languages. This article provides a perspective from one language: Go. We describe analysis complications and the potential for future developments to help practitioners overcome this gap.

Video game development has its own specific nature and problems that differentiate it from general software development. We investigated the influence of these factors in a survey and found a distinct lack of systematic management of technical debt.

All systems have technical debt, and it has to be continuously managed. Thanks to the past decade of research, software engineering teams have now built an awareness and understanding of technical debt as a concept,1 have an improved appreciation of code analysis to drive down unintentional implementation mistakes that may lead to technical debt,2 and even started using some practices to improve its management.3 In fact, arguably, the managing technical debt research agenda, which was initially summarized at the 2010 National Science Foundation Future of Software Engineering Workshop,4 has been one of the few bodies of work in software engineering where we have seen upfront and engaged collaboration among academia, industry, and tool vendors.

Technical debt (TD) can be injected at any stage of software development, spreading across other phases and causing various problems. This article presents a model for conceptualizing TD causes, effects, payment practices, and reasons for payment avoidance, with a prioritization schema for technical and nontechnical roles.

Developers sometimes choose design and implementation shortcuts due to the pressure from tight release schedules. However, shortcuts introduce technical debt that increases as the software evolves. The debt needs to be repaid as fast as possible to minimize its impact on software development and software quality. Sometimes, technical debt is admitted by developers in comments and commit messages. Such debt is known as self-admitted technical debt (SATD). In data-intensive systems, where data manipulation is a critical functionality, the presence of SATD in the data access logic could seriously harm performance and maintainability. Understanding the composition and distribution of the SATDs across software systems and their evolution could provide insights into managing technical debt efficiently. We present a large-scale empirical study on the prevalence, composition, and evolution of SATD in data-intensive systems. We analyzed 83 open-source systems relying on relational databases as well as 19 systems relying on NoSQL databases. We detected SATD in source code comments obtained from different snapshots of the subject systems. To understand the evolution dynamics of SATDs, we conducted a survival analysis. Next, we performed a manual analysis of 361 sample data-access SATDs, investigating the composition of data-access SATDs and the reasons behind their introduction and removal. We identified 15 new SATD categories, out of which 11 are specific to database access operations. We found that most of the data-access SATDs are introduced in the later stages of change history rather than at the beginning. We also observed that bug fixing and refactoring are the main reasons behind the introduction of data-access SATDs.

Background. Self-admitted technical debt (SATD) is a special kind of technical debt that is intentionally introduced and remarked by code comments. Those technical debts reduce the quality of software and increase the cost of subsequent software maintenance. Therefore, it is necessary to find out and resolve these debts in time. Recently, many automatic approaches have been proposed to identify SATD. Problem. Popular IDEs support a number of predefined task annotation tags for indicating SATD in comments, which have been used in many projects. However, such clear prior knowledge is neglected by existing SATD identification approaches when identifying SATD. Objective. We aim to investigate how far we have really progressed in the field of SATD identification by comparing existing approaches with a simple approach that leverages the predefined task tags to identify SATD. Method. We first propose a simple heuristic approach that fuzzily Matches task Annotation Tags ( MAT ) in comments to identify SATD. In nature, MAT is an unsupervised approach, which does not need any data to train a prediction model and has a good understandability. Then, we examine the real progress in SATD identification by comparing MAT against existing approaches. Result. The experimental results reveal that: (1) MAT has a similar or even superior performance for SATD identification compared with existing approaches, regardless of whether non-effort-aware or effort-aware evaluation indicators are considered; (2) the SATDs (or non-SATDs) correctly identified by existing approaches are highly overlapped with those identified by MAT ; and (3) supervised approaches misclassify many SATDs marked with task tags as non-SATDs, which can be easily corrected by their combinations with MAT . Conclusion. It appears that the problem of SATD identification has been (unintentionally) complicated by our community, i.e., the real progress in SATD comments identification is not being achieved as it might have been envisaged. We hence suggest that, when many task tags are used in the comments of a target project, future SATD identification studies should use MAT as an easy-to-implement baseline to demonstrate the usefulness of any newly proposed approach.

Paying-off the Architectural Technical Debt by refactoring the flawed code is important to control the debt and to keep it as low as possible. Project Managers tend to delay paying off this debt because they face difficulties in comparing the cost of the refactoring against the benefits gained. These managers need to estimate the cost and the efforts required to conduct these refactoring activities as well as to decide which flaws have higher priority to be refactored. Our research is based on a dataset used by other researchers that study the technical debt. It includes more than 18,000 refactoring operations performed on 33 apache java projects. We applied the COCOMO II:2000 model to calculate the refactoring cost in person-months units per release. Furthermore, we investigated the correlation between the refactoring efforts and two static code metrics of the refactored code. The research revealed a weak correlation between the refactoring efforts and the size of the project, and a moderate correlation with the code complexity. Finally, we applied the DesigniteJava tool to verify our research results. From the analysis we found a significant correlation between the ranking of the architecture smells and the ranking of refactoring efforts for each package. Using machine learning practices, we took the architecture smells level and the code metrics of each release as an input to predict the levels of the refactoring effort of the next release. We calculated the results using our model and found that we can predict the ‘High’ and ‘Very High’ levels, the most significant levels from managers’ perspective, with [Formula: see text] accuracy.

Code Technical Debt (TD) is intentionally or unintentionally created when developers introduce inefficiencies in the codebase. This can be attributed to various reasons such as heavy workload, tight delivery schedule, or developers’ lack of experience. Since a software system grows mostly through the addition of new code, it is interesting to study how TD fluctuates along this process. Specifically, in this paper, we investigate: (a) the temporality of code TD introduction in new code, i.e., whether the introduction of TD is stable across the lifespan of the project, or if its evolution presents spikes; and (b) the relation of TD introduction to the development team’s workload in a given period, as well as to the experience of the development team. To answer these questions, we have performed a case study on 47 open-source projects from two well-known ecosystems (Apache and Eclipse) as well as additional isolated projects from GitHub (not selected from a specific ecosystem) and inspected the number of TD issues introduced in 6-month sliding temporal windows. The results of the study suggested that: (a) overall, the number of TD issues introduced through new code is a stable measure, although it presents spikes; and (b) the number of commits performed, as well as developers’ experience are not strongly correlated to the number of introduced TD issues.

When deadlines and resources of software projects become scarce, testing is usually in the first row to have its activities aborted or reduced. If defects cannot be found, products quality can be affected. In a software development process, aborted or reduced activities that can bring short-term benefits, but can be harmful to the project in a long run, are considered Technical Debt (TD). When TDs impact testing activities, they are called Test Debt. There are several studies dealing with Test Debt, however, current solutions often deal with specific types of tests (e.g., exploratory and automated tests) and do not address the whole software testing process. Aiming to fill these gaps, this paper proposes a Test Debt Catalog with subtypes of Test Debts and technical debt management activities. This catalog was built based on semi-structured interviews conducted with practitioners who perform testing activities in five projects from industry. With our catalog, we intend to help the management of test debts during the execution of software testing processes.

​© 2020 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works., Serverless computing aims at reducing processing and operational units to single event-driven functions for service orchestration and choreography. With its micro-granular architectural characteristics, serverless computing is bound to face considerable architectural issues and challenges in the medium- and long-term; are these bound to become Technical Debt? As known to many, technical debt is a metaphor that reflects the additional long-run project costs connected to immediately-expedient but unsavvy technical decisions. However, what does technical debt mean and how is it expressed in serverless computing and other hybrid compute models? This article represents the first attempt to conceptualize Technical Debt in such a context; we base our arguments over a technical overview of serverless computing concepts and practices and elaborate on them via empirical inquiry. Our results suggest that higher serviceability of serverless technologies is also characterized by the absence of mechanisms to support an adequate maintainability, testability, and monitoring of serverless systems. Indeed, in case of unexpected behaviours, testing and maintenance activities are more complex and more expensive, as mainly based on non-automated, manual tasks.

Do developers postpone fixing Technical Debt (TD) in software systems? TD is a metaphor that refers to short-term decisions in software development that may affect the cost of the software development life cycle. The bad smell is an imperfect solution in the software system that negatively impacts the internal software quality and maintainability. In this paper, we will study five open-source software projects (OSSPs) that have several releases and also estimate the numbers of architecture smells (ASs), design smells (DSs), and code smells (CSs) for every release. Designite will be used to detect smells. We describe a case study conducted to explore the following: (1) What is the average smells density for architecture, design, and code smells in an OSSP? (2) Does the density of each smell type increase over multiple releases? (3) What percentage of each smell-type density is eliminated by refactoring? We collected around 2 million LOC from five OSSPs that have multiple releases from the GitHub repository to statistically analyze the software concerning the smells as indicators of TD. We find 36% of Architecture Technical Debt (ATD) is Cyclic Dependency, while 33% of Design Debt (DD) is Cyclically-dependent Modularization. More than 70% of Code Debt (CD) is Magic Number. Even though the developers do refactoring between releases, the TD density in general increases. On average, by refactoring, developers remove around 48%, 16%, and 22% from the introduced ATD, DD, and CD from their next release, respectively.

Technical Debt (TD) is a software engineering metaphor that resembles the production of poor- quality code to going into debt. In particular, a development team that ‘‘saves’’ effort while developing by not removing inefficiencies, has to ‘‘pay-back’’ with interest, in the form of additional maintenance costs (i.e., fixing bugs, adding features, etc.) due to the poor maintainability of the developed code. Although maintainability assurance is an established practice in traditional software development (lately known as TD management), it has still not attracted the attention of scientific software developers; i.e., researchers writing code and developing tools for purely research purposes. Nevertheless, based on the literature and practice, maintainability seems to be ranked as an important key-driver for the development of such applications; since the effort needed to update the code before the experimentation (e.g., executing a simulation) is common and should not receive low priority. In this paper, we present the outcome of a 3-year research project on Technical Debt Management (TDM) for scientific software development. The outcome of the project is a framework (termed: EXA2PRO TDM framework) and an accompanying platform for assisting scientific software developers in managing the TD of their applications. The framework is a collection of methods tailored for the mainstream programming languages of scientific software development, which have been empirically validated through five pilot applications. The majority of the EXA2PRO framework suggestions have been applied by scientific software developers and eased future maintenance activities.

There are numerous commercial tools and research prototypes that offer support for measuring technical debt. However, different tools adopt different terms, metrics, and ways to identify and measure technical debt. These tools offer diverse features, and their popularity / community support varies significantly. Therefore, (a) practitioners face difficulties when trying to select a tool matching their needs; and (b) the concept of technical debt and its role in software development is blurred. We attempt to clarify the situation by comparing the features and popularity of technical debt measurement tools, and analyzing the existing empirical evidence on their validity. Our findings can help practitioners to find the most suitable tool for their purposes, and researchers by highlighting the current tool shortcomings.

Writing about the buildup of technical debt, Ward Cunningham said, “Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product.” In this article, I’ll dig into the apparent paradox: how can code work fine and yet be unmasterable? Our code has characteristics of both a machine and pure thought. Technical debt arises when these do not line up. Software developers have a hard time seeing how weird this is because we’re too familiar with our subject. To help us see it from a nonprogrammer perspective, I’m going to try something a bit different in this column. What follows is a fictional conversation between me and a nonprogrammer friend.

Software teams are often asked to deliver new features within strict deadlines leading developers to deliberately or inadvertently serve “not quite right code” compromising software quality and maintainability. This non-ideal state of software is efficiently captured by the Technical Debt (TD) metaphor, which reflects the additional effort that has to be spent to maintain software. Although several tools are available for assessing TD, each tool essentially checks software against a particular ruleset. The use of different rulesets can often be beneficial as it leads to the identification of a wider set of problems; however, for the common usage scenario where developers or researchers rely on a single tool, diverse estimates of TD and the identification of different mitigation actions limits the credibility and applicability of the findings. The objective of this study is two-fold: First, we evaluate the degree of agreement among leading TD assessment tools. Second, we propose a framework to capture the diversity of the examined tools with the aim of identifying few “reference assessments” (or class/file profiles) representing characteristic cases of classes/files with respect to their level of TD. By extracting sets of classes/files exhibiting similarity to a selected profile (e.g., that of high TD levels in all employed tools) we establish a basis that can be used either for prioritization of maintenance activities or for training more sophisticated TD identification techniques. The proposed framework is illustrated through a case study on fifty (50) open source projects and two programming languages (Java and JavaScript) employing three leading TD tools.

Self-admitted technical debt refers to sub-optimal development solutions that are expressed in written code comments or commits. We reproduce and improve on a prior work by Yan et al. (2018) on detecting commits that introduce self-admitted technical debt. We use multiple natural language processing methods: Bag-of-Words, topic modeling, and word embedding vectors. We study 5 open-source projects. Our NLP approach uses logistic Lasso regression from Glmnet to automatically select best predictor words. A manually labeled dataset from prior work that identified self-admitted technical debt from code level commits serves as ground truth. Our approach achieves + 0.15 better area under the ROC curve performance than a prior work, when comparing only commit message features, and + 0.03 better result overall when replacing manually selected features with automatically selected words. In both cases, the improvement was statistically significant (p< 0.0001). Our work has four main contributions, which are comparing different NLP techniques for SATD detection, improved results over previous work, showing how to generate generalizable predictor words when using multiple repositories, and producing a list of words correlating with SATD. As a concrete result, we release a list of the predictor words that correlate positively with SATD, as well as our used datasets and scripts to enable replication studies and to aid in the creation of future classifiers.

These days, everyone uses the term technical debt. It's so prevalent that we shorten it to tech debt tech debt or even just TD. Tech debt is also hacky code, code written by novices, code written without consideration of software architecture (so-called big balls of mud), and code with antipatterns flagged by static analysis tools.

Good data curation is integral to cohort studies, but it is not always done to a level necessary to ensure the longevity of the data a study holds. In this opinion paper, we introduce the concept of data curation debt—the data curation equivalent to the software engineering principle of technical debt. Using the context of UK cohort studies, we define data curation debt—describing examples and their potential impact. We highlight that accruing this debt can make it more difficult to use the data in the future. Additionally, the long-running nature of cohort studies means that interest is accrued on this debt and compounded over time—increasing the impact a debt could have on a study and its stakeholders. Primary causes of data curation debt are discussed across three categories: longevity of hardware, software and data formats; funding; and skills shortages. Based on cross-domain best practice, strategies to reduce the debt and preventive measures are proposed—with importance given to the recognition and transparent reporting of data curation debt. Describing the debt in this way, we encapsulate a multi-faceted issue in simple terms understandable by all cohort study stakeholders. Data curation debt is not only confined to the UK, but is an issue the international community must be aware of and address. This paper aims to stimulate a discussion between cohort studies and their stakeholders on how to address the issue of data curation debt. If data curation debt is left unchecked it could become impossible to use highly valued cohort study data, and ultimately represents an existential risk to studies themselves.

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.

“Hardcoding” is the practice of starkly simplifying program logic to the end of producing software more effectively while sacrificing its versatility and generalizability. Drawing on concepts from science and technology studies and software engineering, this paper develops a case study of hardcoding for the “smart” factory—a kind of factory that leverages the newest information technologies to boost productivity, flexibility, and global competitiveness in existing manufacturing companies. The analysis of the ethnographic material collected through participant observation of a smart factory project in a large technology company suggests that hardcoding serves multiple purposes, which amount to the “specification of ignorance” in software development. In this sense, hardcodes reflect the “yet-to-be-knowns” in a software’s source code while conveying a project’s history of challenges and compromises.

With the advent of regulations protecting users such as the General Data Protection Regulation, security and privacy concerns are playing a new role in small settings such as in very small entities. Their relevance is increasing, and privacy is being considered a Troy horse in software developments. In fact, privacy is a part of software architectural decisions, and they must be considered as a technical debt. The contributions of this paper are the following: a privacy debt definition with a principal and an interest, privacy-related activities to be considered within the ISO/IEC 29110 basic profile, and the use of the net present value within this context. All these contributions help us to integrate privacy debt and VSE's software developments.

Although architectural smells are one of the most studied type of architectural technical debt, their impact on maintenance effort has not been thoroughly investigated. Studying this impact would help to understand how much technical debt interest is being paid due to the existence of architecture smells and how this interest can be calculated. This work is a first attempt to address this issue by investigating the relation between architecture smells and source code changes. Specifically, we study whether the frequency and size of changes are correlated with the presence of a selected set of architectural smells. We detect architectural smells using the Arcan tool, which detects architectural smells by building a dependency graph of the system analyzed and then looking for the typical structures of the architectural smells. The findings, based on a case study of 31 open-source Java systems, show that 87% of the analyzed commits present more changes in artifacts with at least one smell, and the likelihood of changing increases with the number of smells. Moreover, there is also evidence to confirm that change frequency increases after the introduction of a smell and that the size of changes is also larger in smelly artifacts. These findings hold true especially in Medium–Large and Large artifacts.

Self-admitted technical debt (SATD) consists of annotations, left by developers as comments in the source code or elsewhere, as a reminder about pieces of software manifesting technical debt (TD), i.e., “not being ready yet”. While previous studies have investigated SATD management and its relationship with software quality, there is little understanding of the extent and circumstances to which developers admit TD. This paper reports the results of a study in which we asked developers from industry and open-source about their practices in annotating source code and other artifacts for self-admitting TD. The study consists of two phases. First, we conducted 10 interviews to gather a first understanding of the phenomenon and to prepare a survey questionnaire. Then, we surveyed 52 industrial developers as well as 49 contributors to open-source projects. Results of the study show how the TD annotation practices, as well as the typical content of SATD comments, are very similar between open-source and industry. At the same time, our results highlight how, while open-source code is spread of comments admitting the need for improvements, SATD in industry may be dictated by organizational guidelines but, at the same time, implicitly discouraged by the fear of admitting responsibilities. Results also highlight the need for tools helping developers to achieve a better TD awareness.

Context: During software development, some architectural design decisions incur technical debt, either deliberately or inadvertently. These have serious impact on the quality of a software system, and can cost significant time and effort to be changed. While current research efforts have explored general concepts of architectural design decisions and technical debt separately, debt-incurring architectural design decisions have not been specifically explored in practice. Objective: In this case study, we explore debt-incurring architectural design decisions (DADDs) in practice. Specifically, we explore the main types of DADDs, why and how they are incurred in a software system, and how practitioners deal with these types of design decisions. Method: We performed interviews and a focus group with practitioners working in embedded and enterprise software companies, discussing their concrete experience with such architectural design decisions. Results: We provide the following contributions: 1) A categorization for the types of DADDs, which extend a current ontology on architectural design decisions. 2) A process on how deliberate DADDs are made in practice. 3) A conceptual model which shows the relationships between the causes and triggers of inadvertent DADDs. 4) The main factors that influence the way of dealing with DADDs. Conclusion: The results can support the development of new approaches and tools for Architecture Technical Debt management from the perspective of Design Decisions. Moreover, they support future research to capture architecture knowledge related to DADDs.

During the development and maintenance of software-intensive products or services, we depend on various artefacts. Some of those artefacts, we deem central to the feasibility of a project and the product's final quality. Typically, these central artefacts are referred to as assets. However, despite their central role in the software development process, little thought is yet invested into what eventually characterises as an asset, often resulting in many terms and underlying concepts being mixed and used inconsistently. A precise terminology of assets and related concepts, such as asset degradation, are crucial for setting up a new generation of cost-effective software engineering practices. In this position paper, we critically reflect upon the notion of assets in software engineering. As a starting point, we define the terminology and concepts of assets and extend the reasoning behind them. We explore assets' characteristics and discuss what asset degradation is as well as its various types and the implications that asset degradation might bring for the planning, realisation, and evolution of software-intensive products and services over time. We aspire to contribute to a more standardised definition of assets in software engineering and foster research endeavours and their practical dissemination in a common, more unified direction., Manuscript submitted to the Journal of Systems and Software

Refactoring is widely recognized as one of the efficient techniques to manage technical debt and maintain a healthy software project through enforcing best design practices or coping with design defects. Previous refactoring surveys have shown that code refactoring activities are mainly executed by developers who have sufficient knowledge of the system's design and disposing of leadership roles in their development teams. However, these surveys were mainly limited to specific projects and companies. In this paper, we explore the generalizability of the previous results by analyzing 800 open-source projects. We mine their refactoring activities, and we identify their corresponding contributors. Then, we associate an experience score to each contributor in order to test various hypotheses related to whether developers with higher scores tend to 1) perform a higher number of refactoring operations 2) exhibit different motivations behind their refactoring, and 3) better document their refactoring activity. We found that (1) although refactoring is not restricted to a subset of developers, those with higher contribution scores tend to perform more refactorings than others; (2) while there is no correlation between experience and motivation behind refactoring, top contributed developers are found to perform a wider variety of refactoring operations, regardless of their complexity; and (3) top contributed developer tend to document less their refactoring activity. Our qualitative analysis of three randomly sampled projects shows that the developers who are responsible for the majority of refactoring activities are typically in advanced positions in their development teams, demonstrating their extensive knowledge of the design of the systems they contribute to.

The reengineering of systems into a microservice-based architecture can be seen as an implementation of a service-oriented architecture (SOA). However, the deployment of SOA into an enterprise is a challenging task, as it may involve the modernization of mission-critical systems with high technical debt and high maintenance costs. To this end, a process is required to provide an appropriate set of steps and techniques that minimize risks and at the same time ensure the quality of the systems during the migration process. Thus, this work presents the Service-oriented Process for Reengineering and DevOps—SPReaD, an instantiation of the mainstream SOA methodology focusing on the reengineering of legacy systems integrating DevOps aspects for developing microservices systems. This process has been defined during a real software reengineering project of legacy systems from a Brazilian State Department of Taxation. The results obtained include a substantial improvement in the quality of the main taxation system used by the state, including not only code-related metrics but also performance improvements of the services offered, and a change in the methodology adopted by the software development team.

Software Architectural Smells (SA smells) are design problems in the internal structure and behavior of an SA. These can be seen as a specific category under the umbrella concept of Technical Debt (TD). TD is a central concept in software development projects and having the means to detect and measure the smells is important to understand impairments they may cause. However, TD is only limited to the technical aspects and does not describe smells found on an enterprise level. Enterprise Architecture Debt (EAD) expands the concepts of TD beyond the technical aspects such that it covers the debts that can be found in all layers of an Enterprise Architecture (EA). EA smells give a measurement for EAD, by providing means for detecting the smell, hence enabling a method to quantify the level of debt. The goal of this paper is to find EA smells derived from existing SA smells. This has resulted in three new EA smells that could be used as measurements for the quality of an EA. They can also be used in the future as a basis for automatic EA smell detection.

Architectural technical debt (ATD) may create a substantial extra effort in software development, which is called interest. There is little evidence about whether repaying ATD in microservices reduces such interest. Objectives: We wanted to conduct a first study on investigating the effect of removing ATD on the occurrence of incidents in a microservices architecture. Method: We conducted a quantitative and qualitative case study of a project with approximately 1000 microservices in a large, international financing services company. We measured and compared the number of software incidents of different categories before and after repaying ATD. Results: The total number of incidents was reduced by 84%, and the numbers of critical- and high-priority incidents were both reduced by approximately 90% after the architectural refactoring. The number of incidents in the architecture with the ATD was mainly constant over time, but we observed a slight increase of low priority incidents related to inaccessibility and the environment in the architecture without the ATD. Conclusion: This study shows evidence that refactoring ATDs, such as lack of communication standards, poor management of dead-letter queues, and the use of inadequate technologies in microservices, reduces the number of critical- and high-priority incidents and, thus, part of its interest, although some low priority incidents may increase.

Thanks to the increased computing power of processors, developers can develop more complex software applications. Software developers need to follow the software design life cycle to meet consistent high standard software output. The only constant component of software projects is human. The diversity of the teams leads to different understandings during the exchange of information and communication between the teams. Using the traditional method can create inefficient processes and lower quality products. In addition, code readability, code management becomes difficult, and technical debt increases as overtime. The Agile method provides flexibility and high efficiency to teams. Teams that adopt the agile method have advantages in interaction with the customer, in rapid response to changes, and in strong communication. This paper presents the modernization of the teams experiencing the difficulties of the traditional method with the agile method with a real case study. Within the scope of modernization, it has been worked on under three main headings: changing the module-based way of doing business, reducing technical borrowing and renewing distribution strategies. With this transformation, we are able to prioritize customer requests, measure the value of the business, constantly make useful parts available, easily maintain software, and allocate time for new ideas.

Technical debt (TD) is a metaphor to describe the situation where developers introduce suboptimal solutions during software development to achieve short-term goals that may affect the long-term software quality. Prior studies proposed different techniques to identify TD, such as identifying TD through code smells or by analyzing source code comments. Technical debt identified using comments is known as Self-Admitted Technical Debt (SATD) and refers to TD that is introduced intentionally. Compared with TD identified by code metrics or code smells, SATD is more reliable since it is admitted by developers using comments. Thus far, all of the state-of-the-art approaches identify SATD at the file-level. In essence, they identify whether a file has SATD or not. However, all of the SATD is introduced through software changes. Previous studies that identify SATD at the file-level in isolation cannot describe the TD context related to multiple files. Therefore, it is beneficial to identify the SATD once a change is being made. We refer to this type of TD identification as “Change-level SATD Determination”, which determines whether or not a change introduces SATD. Identifying SATD at the change-level can help to manage and control TD by understanding the TD context through tracing the introducing changes. To build a change-level SATD Determination model, we first identify TD from source code comments in source code files of all versions. Second, we label the changes that first introduce the SATD comments as TD-introducing changes. Third, we build the determination model by extracting 25 features from software changes that are divided into three dimensions, namely diffusion, history and message, respectively. To evaluate the effectiveness of our proposed model, we perform an empirical study on 7 open source projects containing a total of 100,011 software changes. The experimental results show that our model achieves a promising and better performance than four baselines in terms of AUC and cost-effectiveness (i.e., percentage of TD-introducing changes identified when inspecting 20 percent of changed LOC). On average across the 7 experimental projects, our model achieves AUC of 0.82, cost-effectiveness of 0.80, which is a significant improvement over the comparison baselines used. In addition, we found that “Diffusion” is the most discriminative dimension among the three dimensions of features for determining TD-introducing changes.

Software companies need to deliver customer value continuously, both from a short- and long-term perspective. However, software development can be impeded by technical debt (TD). Although significant theoretical work has been undertaken to describe the negative effects of TD, little empirical evidence exists on how much wasted time and additional activities TD causes. The study aims to explore the consequences of TD in terms of wastage of development time. This study investigates on which activities this wasted time is spent and whether different TD types impact the wasted time differently. This study reports the results of a longitudinal study surveying 43 developers and including16 interviews followed by validation by an additional study using a different and independent dataset and focused on replicating the findings addressing the findings. The analysis of the reported wasted time revealed that developers waste, on average, 23% of their time due to TD and that developers are frequently forced to introduce new TD. The most common activity on which additional time is spent is performing additional testing. The study provides evidence that TD hinders developers by causing an excessive waste of working time, where the wasted time negatively affects productivity.

Technical debt is a metaphor to reflect the tradeoff software engineers make between short-term benefits and long-term stability. Self-admitted technical debt (SATD), a variant of technical debt, has been proposed to identify debt that is intentionally introduced during software development, e.g., temporary fixes and workarounds. Previous studies have leveraged human-summarized patterns (which represent n-gram phrases that can be used to identify SATD) or text-mining techniques to detect SATD in source code comments. However, several characteristics of SATD features in code comments, such as vocabulary diversity, project uniqueness, length, and semantic variations, pose a big challenge to the accuracy of pattern or traditional text-mining-based SATD detection, especially for cross-project deployment. Furthermore, although traditional text-mining-based method outperforms pattern-based method in prediction accuracy, the text features it uses are less intuitive than human-summarized patterns, which makes the prediction results hard to explain. To improve the accuracy of SATD prediction, especially for cross-project prediction, we propose a Convolutional Neural Network-- (CNN) based approach for classifying code comments as SATD or non-SATD. To improve the explainability of our model’s prediction results, we exploit the computational structure of CNNs to identify key phrases and patterns in code comments that are most relevant to SATD. We have conducted an extensive set of experiments with 62,566 code comments from 10 open-source projects and a user study with 150 comments of another three projects. Our evaluation confirms the effectiveness of different aspects of our approach and its superior performance, generalizability, adaptability, and explainability over current state-of-the-art traditional text-mining-based methods for SATD classification.

Software code quality is important specifically for the maintenance of the software. However, owing to many factors professional software developers accumulate a large amount of technical debt in their code bases. Students are no exception and they also commit code quality issues in their code. In this paper, we perform an exploratory analysis of student projects to understand which code quality issues are prevalent and more frequent. We find that almost all code quality issues are found in student projects. However, Code Style, Documentation, and Design are more frequently found than other issues.

Technical Debt is a metaphor used to express sub-optimal source code implementations that are introduced for short-term benefits that often need to be paid back later, at an increased cost. In recent years, various empirical studies have focused on investigating source code comments that indicate Technical Debt often referred to as Self-Admitted Technical Debt (SATD). Since the introduction of SATD as a concept, an increasing number of studies have examined various aspects pertaining to SATD. Therefore, in this paper we survey research work on SATD, analyzing the characteristics of current approaches and techniques for SATD detection, comprehension, and repayment. To motivate the submission of novel and improved work, we compile tools, resources, and data sets made available to replicate or extend current SATD research. To set the stage for future work, we identify open challenges in the study of SATD, areas that are missing investigation, and discuss potential future research avenues.

Despite the increasing awareness of the importance of managing technical debt in software product development, systematic processes for implementing technical debt management in software production have not been readily available. In this paper we report on the development and field tests of a normative process framework that systematically incorporates steps for managing technical debt in commercial software production. The framework integrates processes required for technical debt management with existing software quality management processes prescribed by the project management body of knowledge (PMBOK), and it contributes to the further development of software-specific extensions to the PMBOK. We partnered with three commercial software product development organizations to implement the framework in real-world software production settings. All three organizations, irrespective of their varying software process maturity levels, were able to adopt the proposed framework and integrate the prescribed technical debt management processes with their existing software quality management processes. Our longitudinal observations and case-study interviews indicate that the organizations were able to accrue economic benefits from the adoption and use of the integrated framework.

Architectural technical debt is the additional project cost connected to technical issues nested in software architectures. Similarly, many practitioners have already experienced that there exists within software architectures a form of social debt, that is, the additional project cost connected to sociotechnical and organizational issues evident in or related to software architectures. This paper illustrates four recurrent antipatterns or community smells connected to such architectural social debt and outlines a means to measure the additional project cost connected to their underlying cause: decision incommunicability. Evaluating the results in multiple focus groups, this paper concludes that studying social debt and community smells at the architecture level may prove vital to rid software development communities of critical organizational flaws incurring considerable additional cost.

Context Software engineering is a human activity. Despite this, human aspects are under-represented in technical debt research, perhaps because they are challenging to evaluate. Objective This study’s objective was to investigate the relationship between technical debt and affective states (feelings, emotions, and moods) from software practitioners. Method Forty participants (N = 40) from twelve companies took part in a mixed-methods approach, consisting of a repeated-measures (r = 5) experiment (n = 200), a survey, and semi-structured interviews. From the qualitative data, it is clear that technical debt activates a substantial portion of the emotional spectrum and is psychologically taxing. Further, the practitioners’ reactions to technical debt appear to fall in different levels of maturity. Results The statistical analysis shows that different design smells (strong indicators of technical debt) negatively or positively impact affective states. Conclusions We argue that human aspects in technical debt are important factors to consider, as they may result in, e.g., procrastination, apprehension, and burnout.