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.

​© 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.

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.

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.

In this excerpt from Episode 332 of Software Engineering Radio, host Jeremy Jung talks with guest John Doran about his experiences repairing the engineering process at Phorest, a Dublin-based company that books appointments in the hair and beauty salon industry. In this excerpt, Doran discusses how technical debt threatened to sink the company, how the company diagnosed the problems, and how it fixed them by changing technology, process, and culture. To hear the full interview, visit http://www.se-radio.net or access our archives via RSS at http://feeds.feedburner.com/se-radio.

Most enterprise IT organizations don’t have a well-defined productivity measure for what flows through their software production process. No clear consensus exists from academia or industry thought leaders on what constitutes software development productivity. Organizations know it when they see it—for example, through products that drive market adoption faster than others. But correlating development activities to those results has been more of an opaque art than a disciplined activity. To define productivity in a value stream, we must first define what flows.

This issue's column reports on the 33rd International Conference on Software Maintenance and Evolution and 32nd International Conference on Automated Software Engineering. Topics include flaky tests, technical debt, QA bots, and regular expressions.

This issue's column reports on the 33rd International Conference on Software Maintenance and Evolution and 32nd International Conference on Automated Software Engineering. Topics include flaky tests, technical debt, QA bots, and regular expressions.

Software is being produced so fast that its growth hinders its sustainability. Technical debt, which encompasses internal software quality, evolution and maintenance, reengineering, and economics, is growing such that its management is becoming the dominant driver of software engineering progress. It spans the software engineering life cycle, and its management capitalizes on recent advances in fields such as source code analysis, quality measurement, and project management. Managing technical debt will become an investment activity applying economic theories. It will effectively address the architecture level and will offer specific processes and tools employing data science and analytics to support decision making. It will also be an essential part of the software engineering curriculum. Getting ahead of the software quality and innovation curve will inevitably involve establishing technical-debt management as a core software engineering practice. This article is part of a special issue on the Future of Software Engineering.

Technical debt refers to maintenance obligations that software teams accumulate as a result of their actions. Empirical research has led researchers to suggest three dimensions along which software development teams should map their technical-debt metrics: customer satisfaction needs, reliability needs, and the probability of technology disruption.

Three IT managers from different domains present their views on the challenges of tackling technical debt.

Technical debt changes the software engineering playing field from qualitative assessment of code quality to quantitative measurement. In so doing, it enables effective governance of the software process.

This article characterizes technical debt across 700 business applications, comprising 357 MLOC. These applications were analyzed against more than 1,200 rules of good architectural and coding practice. The authors present a formula with adjustable parameters for estimating the principal of technical debt from structural quality data.

The metaphor of technical debt in software development was introduced two decades ago to explain to nontechnical stakeholders the need for what we call now "refactoring." As the term is being used to describe a wide range of phenomena, this paper proposes an organization of the technical debt landscape, and introduces the papers on technical debt contained in the issue.

Agile teams create business value by responding to changing business environments and delivering working software at regular intervals. While doing so, they make design tradeoffs to satisfy business needs such as meeting a release schedule. Technical debt is the result of such decisions or tradeoffs. When this happens, agile teams must pay off the accumulated debt by improving designs during subsequent iterations in order to improve maintainability. This must happen in a systematic way so that technical debt does not swell up and damage the project. Accomplishing this is one of the major challenges in distributed agile projects. The scope of technical debt in software projects is spread across all areas including architecture, design, code, and test scripts.

To date, several methods are available for estimating the technical debt present in an application's source code. The SQALE (software quality assessment based on life-cycle expectations) method provides guidance for managing this debt. This article provides some implementation recommendations the authors learned from coaching and assisting large organizations in setting up and using SQALE.

An interview study involving 35 practitioners from a variety of domains aimed to characterize technical debt at the ground level to find out how software practitioners perceive it. The study also aimed to understand the context in which technical debt occurs, including its causes, symptoms, and effects. In addition, the study focused on how practitioners currently deal with technical debt. This analysis paints a picture of a large, complex balancing act of various short- and long-term concerns. The Web Extra gives the interview questions used by Erin Lim, Nitin Taksande, and Carolyn Seaman.

Ward Cunningham coined the term technical debt as a metaphor for the trade-off between writing clean code at higher cost and delayed de livery, and writing messy code cheap and fast at the cost of higher maintenance efforts once it's shipped. Joshua Kerievsky extended the metaphor to architecture and design. Technical debt is similar to financial debt: it supports quick development at the cost of compound interest to be paid later. The longer we wait to garden our design and code, the larger the amount of interest. Discussions of the metaphor have distinguished different types of technical debt and how and when to best pay them off. Most agree that, sooner or later, technical debt will come due. But is this assumption universally true? If it's better to pay interest, what factors influence the decision to service the debt? And if we decide to retire it, what approach should we take?

Technical debt is more than a metaphor: applying finance and accounting practices typical of other business obligations to technical debt can, in addition to meeting ethical and legal governance requirements, generate real, sustained financial benefits.