TechDebt '18- Proceedings of the 2018 International Conference on Technical Debt

Software systems are often developed by many developers who have a varying range of skills and habits. These developers have a big impact on software quality. Understanding how different developers and developer characteristics impact the quality of a software is crucial to properly deploy human resources and help managers improve quality outcomes which is essential for software systems success. Addressing this concern, we conduct a study on how different developers and developer characteristics such as developer seniority in a system, frequency of commits, and interval between commits relate to Technical Debt (TD). We performed a large-scale analysis on 19,088 commits from 38 Apache Java systems and applied multiple statistical analysis tests to evaluate our hypotheses. Our empirical evaluation suggests that developers unequally increase and decrease TD, a developer seniority in a software system and frequency of commits are negatively correlated with the TD the developer induces, and a developer commit interval has a positive correlation with the TD the developer induces.

Architectural Technical Debt (ATD) regards sub-optimal design decisions that bring short-term benefits to the cost of long-term gradual deterioration of the quality of the architecture of a software system. The identification of ATD strongly influences the technical and economic sustainability of software systems and is attracting growing interest in the scientific community. During the years several approaches for ATD identification have been conceived, each of them addressing ATD from different perspectives and with heterogeneous characteristics.

In this paper we apply the systematic mapping study methodology for identifying, classifying, and evaluating the state of the art on ATD identification from the following three perspectives: publication trends, characteristics, and potential for industrial adoption. Specifically, starting from a set of 509 potentially relevant studies, we systematically selected 47 primary studies and analyzed them according to a rigorously-defined classification framework.

The analysis of the obtained results supports both researchers and practitioners by providing (i) an assessment of current research trends and gaps in ATD identification, (ii) a solid foundation for understanding existing (and future) research on ATD identification, and (iii) a rigorous evaluation of its potential for industrial adoption.

Background: Technical debt is currently receiving increasing attention from practitioners and researchers. Several metaphors, concepts, and indications concerning technical debt have been introduced, but no agreement exists about a solid definition of technical debt.

Objective: We aim at providing a solid basis to the definition of technical debt and the way it should be quantified.

Method: We view technical debt as a software quality attribute and therefore we use Measurement Theory, the general reference framework for the quantification of attributes, to define technical debt and its characteristics in a rigorous way.

Results: We show that technical debt should be defined as an external software quality attribute. Therefore, it should be quantified via statistical and machine-learning models whose independent variables are internal software quality attributes. Different models may exist, depending on the specific needs and goals of the software product and development environment. Also, technical debt is a multifaceted concept, so different kinds of technical debt exist, related to different quality attributes, such as performance, usability, and maintainability. These different kinds of technical debt should be evaluated individually, so one can better focus on the specific quality issues that need to be addressed.

Conclusions: We show that, to provide it with a rigorous basis, technical debt should be considered and measured as an external software attribute. Researchers and practitioners should build models for technical debt and use them to (1) assess the extent of the technical debt and (2) investigate and assess different ways of modifying software to repay technical debt.

Database normalization is the one of main principles for designing relational databases. The benefits of normalization can be observed through improving data quality and performance, among the other qualities. We explore a new context of technical debt manifestation, which is linked to ill-normalized databases. This debt can have long-term impact causing systematic degradation of database qualities. Such degradation can be liken to accumulated interest on a debt. We claim that debts are likely to materialize for tables below the fourth normal form. Practically, achieving fourth normal form for all the tables in the database is a costly and idealistic exercise. Therefore, we propose a pragmatic approach to prioritize tables that should be normalized to the fourth normal form based on the metaphoric debt and interest of the ill-normalized tables, observed on data quality and performance. For data quality, tables are prioritized using the risk of data inconsistency metric. Unlike data quality, a suitable metric to estimate the impact of weakly or un-normalized tables on performance is not available. We estimate performance degradation and its costs using Input/Output (I/O) cost of the operations performed on the tables and we propose a model to estimate this cost for each table. We make use of Modern Portfolio Theory to prioritize tables that should be normalized based on the estimated I/O cost and the likely risk of cost accumulation in the future. To evaluate our methods, we use a case study from Microsoft, AdventureWorks. The results show that our methods can be effective in reducing normalization debt and improving the quality of the database.

Software metrics and thresholds provide means to quantify several quality attributes of software systems. Indeed, they have been used in a wide variety of methods and tools for detecting different sorts of technical debts, such as code smells. Unfortunately, these methods and tools do not take into account characteristics of software domains, as the intrinsic complexity of geo-localization and scientific software systems or the simple protocols employed by messaging applications. Instead, they rely on generic thresholds that are derived from heterogeneous systems. Although derivation of reliable thresholds has long been a concern, we still lack empirical evidence about threshold variation across distinct software domains. To tackle this limitation, this paper investigates whether and how thresholds vary across domains by presenting a large-scale study on 3,107 software systems from 15 domains. We analyzed the derivation and distribution of thresholds based on 8 well-known source code metrics. As a result, we observed that software domain and size are relevant factors to be considered when building benchmarks for threshold derivation. Moreover, we also observed that domain-specific metric thresholds are more appropriated than generic ones for code smell detection.

One of the biggest challenges in a large software development project is to manage technical debt. For example, if an API is replaced by a newer version and the old one is deprecated, there is a big risk that a substantial technical debt is incurred. The time where two versions of an API can co-exist can be quite long, and in a big organization like Ericsson 4G5G Baseband there can be a big challenge to prevent developers from continuing to use deprecated API's. At Ericsson 4G5G Baseband we invented the tool debtgrep to be incorporated in our Continuous Integration machinery. The tool will prevent any new code to be added using deprecated API's, or other configured keywords. The tool has proven very useful in the development of a new product based on a new software architecture. Debtgrep is used for deprecated API's, enforcing design rules, and enforcing architecture rules. The paper describes the behavior and configuration possibilities of the tool, and how it is used at Ericsson 4G5G Baseband.

This paper identifies a small, essential set of static software code metrics linked to the software product quality characteristics of reliability and maintainability and to the most commonly identified sources of technical debt. An open-source plug-in is created for the Understand code analysis tool that calculates and visualizes these metrics. The plug-in was developed as a first step in an ongoing project aimed at applying case-based reasoning to the issue of software product quality.¹

It is challenging to assess and manage Technical Debt. Technical Debt is avoided or refactored if the long-term benefits, such as preventing extra-costs, exceed the cost of repaying the debt.

Some tools have been recently proposed for the identification of Technical Debt, but most of them do not help in assessing the cost-benefits of repaying the Debt. Besides, it is challenging to track, visualize and plan Technical Debt refactoring systematically. Although practitioners might use simple tracking tools, calculating and communicating Technical Debt is currently not supported.

Based on the results of previous research, combined with several practical experiences in collaboration with large software companies, we have developed and evaluated a lightweight tool, AnaConDebt, to track and assess Technical Debt.

As a measure of understandability, Cyclomatic Complexity is widely regarded as unsatisfactory, but until December 2016 it was the only one available. This paper describes Cognitive Complexity, a new metric designed specifically to measure understandability, and a brief survey of Cognitive Complexity issues in a subset of open source projects under static analysis on SonarCloud. From this analysis, an assessment is made of whether Cognitive Complexity is accepted or rejected by the developers of each project.

Large-scale systems often contain considerable amounts of code that is overly complicated, hard to understand, and hence expensive to change. An organization cannot address and refactor all of that code at once, nor should they. Ideally, actionable refactoring targets should be prioritized based on the technical debt interest rate to balance the trade-offs between improvements, risk, and new features. This paper examines how CodeScene, a tool for predictive analyses and visualizations, can be used to prioritize technical debt in a large-scale codebase like the Linux Kernel based on the most likely return on code improvements.

While technical debt has emerged as a formal concept relatively recently [2] we have had technical debt from the earliest days of software development, it has simply evolved in nature. So what can we learn from past types of technical debt to allow us to prepare for its future forms?

When we look back over recent software history, we can see five identifiable evolutions of software systems [5], each one roughly aligning with a decade.

Before and through the 1980s, software systems were largely monolithic and tended to run on single computers, with software being developed as monolithic "programs". As we moved into the 1990s, distributed systems became mainstream and the standard style for an enterprise system became three-tier client server. The Internet became a mainstream technology in the late 1990s, and organisations developed Internet-connected systems, which were "always on" rather than just "online" and could support difficult and unpredictable quality properties. In the current era, we are building Internet-native systems, where "the Internet is the system". These systems are built from a combination of open source components, remote Internet connected services and custom code, and their services often form part of the Internet via publicly accessible APIs.

Following current trends, it seems that the next phase of evolution will be to Intelligent-Connected systems, as artificial intelligence (machine learning in particular) becomes mainstream [1], users expect context specific assistance, and fast, reliable networks allow us to connect "things" (devices) to our systems as well as traditional computers [3].

Software engineering practice evolves in response to new challenges and each era of computing has introduced new techniques and technology but each has also introduced its own types of technical debt too.

In the monolithic era, the focus was structuring a single program, with "spaghetti code", poor naming and unrestricted use of the "goto" emerging as examples of the earliest types of technical debt. As we moved into the distributed era, we ended up tangling presentation and business logic code in our client/server user interfaces, while in the Internet-connected era we distorted our systems to meet performance and scalability concerns at all costs and often ended up with poorly-designed automated tests being an inflexible technical debt of their own. More recently Internet-native systems often introduce a mishmash of microservices with poorly understood choreography and diverse internal implementations, references to external APIs that became unsupported or difficult to use and public APIs with many versions, all of which have to be maintained "forever" due to callers who would not migrate to new versions.

So what types of technical debt do we expect in the future?

In the intelligent-connected era, amongst other things, applications will have machine learning features and we'll need large datasets to train machine learning models and provide context-specific user experiences and we'll have lots of non-computing devices connected to our systems, providing data. So we'll probably get machine learning debt [4], ML models that we can't explain, models that we can't improve because people rely on their quirks (even if wrong). We'll also have large inflexible data sets which our systems and models rely on, and we'll have unknown and unpredictable collections of "things" connecting to our services, which we can't change because other people own them.

While this sounds like a daunting set of challenges, the intelligent-connected era is only just beginning, so we have not yet incurred significant amounts of technical debt. By looking to the past as our guide to the future we can be forewarned and start find solutions to our future technical debt before we have become overwhelmed by it!

The set of concepts collectively known as Technical Debt (TD) assume that software liabilities set up a context that can make a future change more costly or impossible; and therefore repaying the debt should be pursued. However, software developers often disagree with an automatically generated list of improvement suggestions, which they consider not fitting or important for their own code. To shed light into the reasons that drive developers to adopt or reject refactoring opportunities (i.e. TD repayment), we have performed an empirical study on the potential factors that affect the developers' decision to agree with the removal of a specific TD liability. The study has been addressed to the developers of four well-known open-source applications. To increase the response rate, a personalized assessment has first been sent to each developer, summarizing his/her own contribution to the TD of the corresponding project. Responds have been collected through a custom built web application that presented code fragments suffering from violations as identified by SonarQube along with information that could possibly affect their level of agreement to the importance of resolving an issue. These factors include data such as the frequency of past changes in the module under study, the number of bugs, the type and intensity of the violation, the level of involvement of the developer and whether he/she is a contributor in the corresponding project. Multivariate statistical analysis methods have been used to understand the importance and the underlying relationships among these factors and the results are expected to be useful for researchers and practitioners in TD Management.

In this paper, we propose a model that formalizes the role of software evolution in characterizing Technical Debt (TD) by defining a series of software product states, where each successive state represents an increased level of maintenance code churn, and thus presumably an increased level of change difficulty. We also propose a way to use these states to estimate TD principal and interest and use this information in decision making during release planning. In addition, we illustrate our model using bug report data from the Eclipse-Birt project.

Commercial software development projects frequently build code on third-party components. However, depending on third-party code requires that projects keep current with the latest version of each component. When projects do not stay current, they begin to incur a form of technical debt where API calls that have been deprecated remain in the code base. At some point, projects must upgrade the third-party component to remain on a supported version of the component. Then the projects incur the cost of paying down the debt that was built up over time. The model described herein intends to estimate the cost of paying down the debt for aging third-party components.

The model is a sigmoid curve that exponentially increases the size of changes required to migrate to the new version as a function of time asymptotically approaching the size for replacing the entire component. The longer the number of elapsed years, the greater the increase in the principal measured as the number of affected lines of code in the user of the third-party software component. This exponential increase in principal is reasonable when we consider longer time horizons are more likely to require replacement of the third-party component entirely due to newer technologies becoming available. Effects of the model were estimated using Monte Carlo simulation due to limited examples of third-party technical debt available for modeling.

Technical debt has successfully captured the interest of practitioners and researchers alike. We argue that the concept of technical debt holds much more currency within the strategic Information Systems literature. Hence, we have developed a research framework for expanding the concept of technical debt into a new concept we dub "technology debt". This expanded concept aims at capturing the path-dependencies reported in literature in regard to digital investments, and to make these both researchable and manageable. Technology debt is defined as the constraining effects of previous governance decisions on future decisions, including technical debt as important factor, but not unique. According to the findings, technology debt is a feasible method for highlighting the constraining aspects of IT investments and including these in the investment evaluation by governing body. This offers support for corporate stakeholders involved in the decision-making surrounding IT related investments, particularly in IT governance and management processes.

Technical Debt arises from decisions that favour short-term outcomes at the cost of longer-term disadvantages. They may be taken knowingly or based on missing or incomplete awareness of the costs; they are taken in different roles, situations, stages and ways. Whatever technical or business factor motivate such decisions, they always imply a trade-off in time, a 'now vs. later'. How exactly are such decisions made, and how have they been studied?

This paper analyzes how decisions on technical debt are studied in software engineering via a systematic literature review. It examines the presently published Software Engineering research on Technical Debt, with a particular focus on decisions involving time. The findings reveal surprising gaps in published work on empirical research in decision making. We observe that research has rarely studied how decisions are made, even in papers that focus on the decision process. Instead, most attention is focused on engineering measures and feeding them into an idealized decision making process. These findings lead to a set of recommendations for future empirical research on Technical Debt.

Technical debt (TD) in a software system is a metaphor that tries to illustrate the remediation effort of the already introduced quality deficit and the impact thereof to the business value of the system. To address TD, various management activities are proposed, each addressing a particular purpose. Whereas the activities of debt identification and measurement are broadly considered in literature, the activities of debt prioritization and communication lack appropriate approaches with an economic perspective. This work proposes a TD prioritization approach. Therefore, it narrows down the focus of TD to design debt and relies on the quantification of design best practices. Further, the non-conformance of these practices is assessed by applying a benchmarking technique. As a result, the gained information is transferred into a portfolio-matrix to support the prioritization and communication of design remediation actions. The applicability and suitability of the approach are demonstrated by using the source code of the open source project GeoGebra.

Software companies need to continuously deliver customer value, both from a short- and long-term perspective. However, software development can be impeded by what has been described as Technical Debt (TD). The aim of this study is to explore the negative consequences of TD in terms of wasted software development time. This study also investigates on which additional activities this wasted time is spent and whether different types of TD impact the wasted time differently. This study also sets out to examine the benefits of tracking and communicating the amount of wasted time, both from a developer's and manager's perspective. This paper reports the results of a longitudinal study, surveying 43 software developers, together with follow-up interviews with 16 industrial software practitioners. The analysis of the reported wasted time revealed that developers waste, on average, 23% of their development time due to TD and that they are frequently forced to introduce new TD due to already existing TD. The most common activity on which additional time is spent is performing additional testing.

Technical debt management entails the quantification of principal and interest. In our previous work we had introduced a framework for calculating the Technical Debt Breaking Point (TD-BP), which is a point in time where the accumulated interest becomes larger than the principal; thus the debt of the company is no longer sustainable after this point in time. In this paper, we instantiate this framework and validate its ability to assess the breaking point of source code modules in an industrial setting. The results of the validation suggest that the calculated TD-BP is strongly correlated to experts' opinion on the sustainability of modules, and that it can accurately rank components, based on their maintenance difficulty.

Maintainability assurance techniques are used to control this quality attribute and limit the accumulation of potentially unknown technical debt. Since the industry state of practice and especially the handling of Service- and Microservice-Based Systems in this regard are not well covered in scientific literature, we created a survey to gather evidence for a) used processes, tools, and metrics in the industry, b) maintainability-related treatment of systems based on service-orientation, and c) influences on developer satisfaction w.r.t. maintainability. 60 software professionals responded to our online questionnaire. The results indicate that using explicit and systematic techniques has benefits for maintainability. The more sophisticated the applied methods the more satisfied participants were with the maintainability of their software while no link to a hindrance in productivity could be established. Other important findings were the absence of architecture-level evolvability control mechanisms as well as a significant neglect of service-oriented particularities for quality assurance. The results suggest that industry has to improve its quality control in these regards to avoid problems with long-living service-based software systems.

This position paper proposes a new stream of research targeted at technical debt as a source of information asymmetry between finance and IT professionals involved in information technology investment decisions. Finance teams interact with technology teams in several ways, predominantly when business cases require review and during the annual budgeting process. During these discrete interactions, finance teams are required to digest large amounts of technical strategy and architectural information chock-full of technical terminology and diagrams. Typically, the estimates for effort are soft and risk is difficult to measure. It is within this context that finance approves budgets and projects that inevitably result in the accumulation of technical debt. This paper discusses some of the dynamics at work between finance and IT teams within large complex organizations when they meet to make technology investment decisions. In addition, future research is proposed aimed at reducing information asymmetry, thereby leading to improved IT investment decisions and better management of technical debt.¹

Context: Managing technical debt (TD) associated with potential security breaches found during design can lead to catching vulnerabilities (i.e., exploitable weaknesses) earlier in the software lifecycle; thus, anticipating TD principal and interest that can have decidedly negative impacts on businesses. Goal: To establish an approach to help assess TD associated with security weaknesses by leveraging the Common Weakness Enumeration (CWE) and its scoring mechanism, the Common Weakness Scoring System (CWSS). Method: We present a position study with a five-step approach employing the Quamoco quality model to operationalize the scoring of architectural CWEs. Results: We use static analysis to detect design level CWEs, calculate their CWSS scores, and provide a relative ranking of weaknesses that help practitioners identify the highest risks in an organization with a potential to impact TD. Conclusion: CWSS is a community agreed upon method that should be leveraged to help inform the ranking of security related TD items.