TechDebt '20: Proceedings of the 3rd International Conference on Technical Debt

Full Citation in the ACM Digital Library

SESSION: Research/Experience/Education/Short Papers

A systematic literature review of technical debt prioritization

Repaying all technical debt (TD) present in a system may be unfeasible, as there is typically a shortage in the resources allocated for TD repayment. Therefore, TD prioritization is essential to best allocate such resources to determine which TD items are to be repaid first and which items are to be delayed until later releases. This study conducts a systematic literature review (SLR) to identify and analyze the currently researched TD prioritization approaches. The employed search strategy strove to achieve high completeness through the identification of a quasi-gold standard set, which was used to establish a search string to automatically retrieve papers from select research databases. The application of selection criteria, along with forward and backward snowballing, identified 24 TD prioritization approaches. The analysis of the identified approaches revealed a scarcity of approaches that account for cost, value, and resources constraint and a lack of industry evaluation. Furthermore, this SLR unveils potential gaps in the current TD prioritization research, which future research may explore.

An empirical study on self-fixed technical debt

Technical Debt (TD) can be paid back either by those that incurred it or by others. We call the former self-fixed TD, and it is particularly effective, as developers are experts in their own code and are best-suited to fix the corresponding TD issues. To what extent is TD self-fixed, which types of TD are more likely to be self-fixed and is the remediation time of self-fixed TD shorter than non-self-fixed TD? This paper attempts to answer these questions. It reports on an empirical study that analyzes the self-fixed issues of five types of TD (i.e., Code, Defect, Design, Documentation and Test), captured via static analysis, in more than 17,000 commits from 20 Python projects of the Apache Software Foundation. The results show that more than two thirds of the issues are self-fixed and that the self-fixing rate is negatively correlated with the number of commits, developers and project size. Furthermore, the survival time of self-fixed issues is generally shorter than non-self-fixed issues. Moreover, the majority of Defect Debt tends to be self-fixed and has a shorter survival time, while Test Debt and Design Debt are likely to be fixed by other developers. These results can benefit both researchers and practitioners by aiding the prioritization of TD remediation activities within development teams, and by informing the development of TD management tools.

Carrot and stick approaches when managing technical debt

When developing software, it is vitally important to keep the level of technical debt down since it is well established from several studies that technical debt can, e.g., lower the development productivity, decrease the developers' morale, and compromise the overall quality of the software. However, even if researchers and practitioners working in today's software development industry are quite familiar with the concept of technical debt and its related negative consequences, there has been no empirical research focusing specifically on how software managers actively communicate and manage the need to keep the level of technical debt as low as possible.

This paper aims to explore how software companies encourage and reward practitioners for actively keeping the level of technical debt down and also whether the companies use any forcing or penalizing initiatives when managing technical debt.

This paper reports the results of both an online web-survey provided quantitative data from 258 participants and follow-up interviews with 32 industrial software practitioners. The findings show that having a TD management strategy can significantly impact the amount of TD in the software. When surveying how commonly used different TD management strategies are, we found that only the encouraging strategy is, to some extent, adopted in today's' software industry. This study also provides a model describing the four assessed strategies by presenting its strategies and tactics, together with recommendations on how they could be operationalized in today's software companies.

Detecting bad smells with machine learning algorithms: an empirical study

Bad smells are symptoms of bad design choices implemented on the source code. They are one of the key indicators of technical debts, specifically, design debt. To manage this kind of debt, it is important to be aware of bad smells and refactor them whenever possible. Therefore, several bad smell detection tools and techniques have been proposed over the years. These tools and techniques present different strategies to perform detections. More recently, machine learning algorithms have also been proposed to support bad smell detection. However, we lack empirical evidence on the accuracy and efficiency of these machine learning based techniques. In this paper, we present an evaluation of seven different machine learning algorithms on the task of detecting four types of bad smells. We also provide an analysis of the impact of software metrics for bad smell detection using a unified approach for interpreting the models' decisions. We found that with the right optimization, machine learning algorithms can achieve good performance (F1 score) for two bad smells: God Class (0.86) and Refused Parent Bequest (0.67). We also uncovered which metrics play fundamental roles for detecting each bad smell.

Experiences with technical debt and management strategies in production systems engineering

Technical Debt (TD) has proven to be a suitable communication concept for software-intensive contexts to raise awareness regarding longterm negative effects of deviations from standards and guidelines. TD has also been introduced to systems engineering domain, to communicate design shortcomings in long-running, software-assisted systems. We analysed potential TD in the engineering data exchange for production system engineering. Similar to requirements engineering in software-intensive systems, data exchange in the design phase plays an integral part in Software Engineering (SE) for Production Systems Engineering: Specifications, and physical logic have to be derived from heterogeneous plant models or parameter tables designed by different stakeholders. However, traditional procedures and inadequate tool support lead to inefficient data extraction and integration. We identified debt arising from knowledge representation, data model and the exchange process. The refinement validation of identified TD was achieved through semi-structured interviews with representatives in two analysed companies. In an online survey with ten participants from an industrial consortium we evaluated whether the identified TD concepts also applied to other companies, which is true for the majority of TD. Furthermore, we discuss promising TD management strategies to repay and manage negative effects and the accumulation of additional debt, such as improved communication, test-driven model engineering and visualisation of engineering models.

How junior developers deal with their technical debt?

Technical debt is a metaphor that measures the additional effort needed to continue to add more features in a software due to its inherent decrease in code quality. Most software systems suffer from technical debt at some point so that dedicated tools and metrics have been developed to monitor such debt. Alongside tools, appropriate engineering practices must be put in place by the development team to keep that debt at an acceptable level. In this empirical study, we observed and surveyed Scrum development teams composed of experienced students in order to understand their quality-related processes on a year-long academic project. We found that (1) students do use static analysis tools of many forms, but their actual usage is limited due to time pressure; (2) retrospective and non-constraining feedback on code quality has little to no effect, even when given regularly during the course of the project; and (3) junior developers value composite quality indicators (e.g., maintainability, reliability in SonarQube), even if they do not fully understand their meaning. From our findings, we propose a series of recommendations, both technical and methodological, on how to train junior developers to understand and manage technical debt.

On energy debt: managing consumption on evolving software

This paper introduces the concept of energy debt: a new metric, reflecting the implied cost in terms of energy consumption over time, of choosing a flawed implementation of a software system rather than a more robust, yet possibly time consuming, approach. A flawed implementation is considered to contain code smells, known to have a negative influence on the energy consumption.

Similar to technical debt, if energy debt is not properly addressed, it can accumulate an energy "interest". This interest will keep increasing as new versions of the software are released, and eventually reach a point where the interest will be higher than the initial energy debt. Addressing the issues/smells at such a point can remove energy debt, at the cost of having already consumed a significant amount of energy which can translate into high costs. We present all underlying concepts of energy debt, bridging the connection with the existing concept of technical debt and show how to compute the energy debt through a motivational example.

The hidden cost of backward compatibility: when deprecation turns into technical debt - an experience report

Context The micro-services architectural pattern advocates for the partitioning of functionality into loosely coupled services, which should be backward compatible, to enable independent upgrades. Deprecation is commonly used as a tool to manage multiple versions of methods or services. However, deprecation carries a cost in that tests might be duplicated and might rely on services that have become deprecated over time.

Objective Using the terms of the Technical Debt metaphor, we explore the consequences of deprecation, and how it has affected the test base during seven years.

Method We take an exploratory approach, reporting on experiences found before and after servicing parts of the incurred Technical Debt. We mine code repositories and validate our findings with experienced developers.

Results We found that the growth of deprecation debt varied a lot. Some services experienced substantial growth, but most did not. Unit tests, where deprecation is visible in the developers' tools, were much less affected than integration tests, which lack such visualization mechanisms. While servicing debt of 121 out of 285 deprecated services, we discovered that up to 29% of the spent effort could be attributed to accrued interest. However, this is an upper bound; there could be less impact, depending on whether scripting could be used to service the debt or not.

Conclusion This paper illustrates that integration tests can be viewed as a debt from the perspective of deprecated services. While the pattern was that deprecated services (debt principal) experienced no or little accrued interest, some, highly used, services experienced a lot, particularly during stressful times. Java-based tests, where deprecation is visible in the IDE, did not experience a similar pattern of increasing debt. We postulate that deprecation debt should be kept visible, either using developer tools or statistical reports.

The prevalence of the technical debt concept in serbian IT industry: results of a national-wide survey

Background: There is a growing body of knowledge on Technical Debt (TD) in recent years. This knowledge provides various explanations of the term and suggests different remedies for it. However, the knowledge is yet to be validated in software development processes. Aims: The objective of this study is twofold. First, to get empirical insight on the understanding and the use of the TD concept in Serbian IT industry. Second, to contribute towards precise conceptualization of the TD concept. Method: We conducted a national-wide survey to collect feedback from industry practitioners. The survey is a part of InsighTD-an international initiative to investigate causes and effects of TD. Results: In total, 93 responses were collected, mostly from developers. Results indicate that the concept of TD is not widely accepted for use by the industry, only 35% of practitioners have practical experiences with projects that explicitly considered or managed TD. The most common types of TD are: code, test and design debt that together account for 61% of all reported cases. The archetypal TD case is caused by a tight schedule and resulted with non-optimal solutions that are difficult to evolve and in constant need of rework. Conclusions: Implications are at one hand for academics, who should consider TD as a topic for their curriculums since the results revealed that novice developers are unfamiliar with the concept. At the other hand, industry practitioners have a well aligned understanding of the TD concept, which is consistent with TD literature. However, we perceive that the wider use of the existing tools and techniques for managing TD can significantly help practitioners to deal with the top three occurring TD types.

Towards collaborative technical debt management in systems of systems

Systems Engineering is a matter of the perspective and scope where several principles of the systems thinking approach coincide. Following the fundamental system principle of holism and interaction theory, in order to understand the whole the system should be considered as a whole. Due to the phenomena of emergence, not all properties of a system can be determined or explained by its components alone. The conceptual model of Technical Debt already recognize the context sensitivity of Technical Debt as an essential factor and identifies phenomena that fall outside the core definition of Technical Debt as a major part of future research.

This short paper shows why managing the parts does not equal managing the whole by introducing Technical Debt as an emergent characteristic and why the traditional Technical Debt-Management methods can only be partially applied to Systems of Systems.

Towards microservice smells detection

With the adoption of microservices architectural styles, practitioners started noticing increasing pitfalls in managing and maintaining such architectures, with the risk of introducing architectural debt. Previous studies identified different microservice smells (also named anti-patterns) that harm microservices architectures. However, according to our knowledge, there are no tools that can automatically detect microservice smells, so their identification is left to the experience of the developer. In this paper, we extend an existing tool developed for the detection of architectural smells to explore microservices architecture through the detection of three microservice smells: Cyclic Dependencies, Hard-Coded Endpoints, and Shared Persistence. We detected the smells on five open-source projects implemented with microservices and manually validated the precision of the detection results. This work aims to open new perspectives on facing and studying architectural debt in the field of microservices architectures.

Trade-offs in managing risk and technical debt in industrial research labs: an experience report

Nowadays, industrial research labs operate like startups. In a relatively short amount of time, researchers are expected not only to explore innovative ideas but also show how the new ideas can add value to the organisation. One way to do this, especially when developing tools, is to construct usable prototypes. When the technology underlying the research tool is highly complex or niche, like program analysis, field trials with potential users also help explaining and demonstrating the benefits of the tool. Getting support from potential users helps demonstrate value to the organisation, which in turn justifies conducting more extensive research and investing more resources to enhance the initial prototype.

Thus, research that involves the construction of tools need to manage both short and long term risk, and the technical debt that arises throughout the lifecycle of a research prototype. As not all prototypes will result in a technology transfer, one has to carefully manage the project resources dedicated to paying the technical debt. For example, failure to pay the debt early in the project might result in unstable prototypes that can have a negative influence on potential customers and make technology transfer harder. On the other hand, over committing resources to reduce the technical debt might result in slower research progress and failure to show improvement over state-of-the-art. In this paper, we will present experience reports from two dynamic program analysis projects. at Oracle Labs Australia.

What are the practices used by software practitioners on technical debt payment: results from an international family of surveys

Context: Technical debt (TD) is a metaphor used to describe technical decisions that can give the company a benefit in the short term but possibly hurting the overall quality of the software in the long term. Objective: This study aims to characterize the current state of practices related to TD payment from the point of view of software practitioners. Method: We used a survey research method to collect and analyze - both quantitatively and qualitatively - a corpus of responses from a survey of 432 software practitioners from Colombia, Chile, Brazil, and the United States, as a part of the InsighTD project. Results: We were able to identify that refactoring (24.3%) was the main practice related to TD payment, along with improving testing (6.2%) and improve design (5.8%). Also, we identify that small-sized systems and big-sized systems, along with young systems (less than one year) tend to use more refactoring. As a part of these results, we also could identify that some practices do not eliminate the debt by itself, but support a favorable scenario for TD payment or prevention. Additionally, after comparing the three major TD types cited (code debt, test debt and design debt) we could discover an important similarity of TD payment practices between code debt and design debt. Lastly, we identified that no matter the cause leading to TD occurrence, refactoring remained the most common practice. Conclusion: Definition of practices related to TD payment is an essential activity for software development teams. Developing healthy software systems that can be maintained in the future requires that companies find the right approaches for TD payment.

SESSION: Tools track papers

Skuld: a self-learning tool for impact-driven technical debt management

As the development progresses, software projects tend to accumulate Technical Debt and become harder to maintain. Multiple tools exist with the mission to help practitioners to better manage Technical Debt. Despite this progress, there is a lack of tools providing actionable and self-learned suggestions to practitioners aimed at mitigating the impact of Technical Debt in real projects. We aim to create a data-driven, lightweight, and self-learning tool positioning highly impactful refactoring proposals on a Jira backlog. Bearing this goal in mind, the first two authors have founded a startup, called, with the vision of becoming the go-to software renovation company. In this tool paper, we present the software architecture and demonstrate the main functionalities of our tool. It has been showcased to practitioners, receiving positive feedback. Currently, its release to the market is underway thanks to an industry-research institute collaboration with Fraunhofer IESE to incorporate self-learning technical debt capabilities.

Software archinaut: a tool to understand architecture, identify technical debt hotspots and manage evolution

In this paper we present Software Archinaut-a tool used to help identify technical debt hotspots in an architecture, and manage the evolution of the architecture once these hotspots are discovered. Archinaut is a platform that integrates analyses from different tools. It supports three main usage scenarios: 1) understanding the architecture, 2) identifying technical debt hotspots, and 3) monitoring and controlling the evolution of the architecture. We illustrate these scenarios by using Apache Kafka as an example.