Understanding and Managing Technical Debt

Georges Lteif

Georges Lteif

Software Engineer

Last Updated on May 19, 2022.
Subscribe now to stay posted!
About Us
4 min read

1. Overview

Technical debt is a concept first coined by Ward Cunningham, one of the co-authors of the Agile manifesto.

When recounting the story, he explains how he used the metaphor of financial debt to explain why they needed to refactor part of an existing codebase for a product they were developing. Somehow, the business stakeholders needed to justify spending money on something already working. From there on, the term technical debt took off.

The story recounted by Cunnigham goes like this:


With borrowed money, you can do something sooner than you might otherwise, but then until you pay back that money you’ll be paying interest. I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.
Ward Cunningham

Technical debt is an important concept as it allows us to characterize in familiar terms an aspect of code quality that is otherwise difficult to grasp.


2. Table of Contents


3. What Is Technical Debt

3.1 Definition

You accumulate technical debt when you decide to sacrifice a portion of design or quality to make an early release. These sacrifices include achieving and sustaining wider test coverage or better code extensibility.

The argument that supports accepting technical debt today, is that this debt will be paid later through refactoring when better knowledge or more time is available to the developers.

Delivering complex functionality necessitates complex code. If, however, the code is burdened with technical debt, a portion of this complexity would be unjustified and would hinder efficient future changes.

3.2 Technical Debt: Intentional or Unintentional?

There is a subtle difference between bad code and technical debt. While bad code results from poor coding practices or lack of skills, technical debt is the price we choose to pay to release code that is not in its best shape.

In the former case, we are typically unaware that the code is bad. However, in the latter case, a risk-informed decision is made to release software that we acknowledge would benefit from additional work.

The view we take in this article on whether technical debt is intentional, unintentional, or both is based on the original interpretation by Ward Cunnigham. (ref. article) as well as other influential figures in the software world like Bob Martin who emphasized in this article that “A Mess is not a Technical Debt”.

A different opinion by Steve McConnell (cited in this research paper) stated that technical debt could be unintentional such as, for example, due to poor programming skills or the usage of an inconsistent coding style.

We believe the conservative definition to be closest to what the original author had in mind, and therefore, we will be using that definition throughout this text.

3.3 Sources of Technical Debt

There are several scenarios where the risk of taking on technical debt is deemed acceptable:

  • You are pressured by project schedule or budget constraints to use architecture or implementation with known and acceptable limitations.
  • Old solutions may not age well and become obsolete. You can decide to fix them now at the risk of derailing the next release or accept them as technical debt and postpone their refactoring to a more convenient time.
  • Developers simultaneously working on many feature branches create the additional risk of accrued technical debt. Collaboration is required to synchronize views, share knowledge, and align plans. The more features are developed in isolation, and teams working in silos, the higher the technical debt.

You accept technical debt today to gain valuable knowledge tomorrow. You must, however, use that knowledge to refactor the code once your understanding is improved. Together, these two steps form the basis of the proper use of technical debt.

3.4 Technical Debt Is Hidden

Technical debt is primarily visible only to the developer. When a software product’s shortcomings are obvious to the business stakeholder or end-user, they are not considered technical debt; the value of addressing them can be directly observed and measured.

On the other hand, missing documentation, poor architecture or design, or low test coverage are not evident to the non-technical stakeholder and present a risk because their future impact cannot be precisely determined and therefore is difficult to manage.


4. Types of Technical Debt

A research team investigated the literature on technical debt and published a paper listing its different types. Below are a few examples Of the thirteen classifications identified:

  • Architecture DebtArchitecture debt consists of issues such as non-modular designs, ad-hoc interfaces, and structural coupling and dependencies.
  • Design Debt — This category includes issues like strong coupling, large classes, duplicated code, or any violation of the software design principles like S.O.L.I.D‘s Single Responsibility Principle or Interface Segregation.
  • Coding Debt — Coding debt can be slow algorithms, obsolete solutions, lack of design pattern usage, and duplicated code.
  • Documentation Debt — Poor, outdated, or missing documentation is the central theme of this class.
  • Test Debt — Poor coverage, manual testing, and testing implementation rather than functionality.

5. Managing Technical Debt

Below are a few ideas to keep in mind when thinking about technical debt.

  • Technical debt must be managed. We have mentioned earlier that you only accept the risk of taking on technical debt if you intend to pay it off later. If you don’t attend to it by continuous refactoring, your changes will become more and more expensive, and your profit margins will disappear. In the long term, your code will turn from asset to liability.
  • You can optimize time spent on managing technical debt by not having to refactor code that doesn’t frequently change. If it works fine, you can let it be. On the other hand, frequently changed code should remain in optimal shape. Every time you update that code, you can dedicate a percentage of that effort to refactoring it.
  • You can benefit from tools such as SonarQube to automate the detection and tracking of technical debt by integrating static code analysis into your Continuous Integration pipelines. Static code analysis tools allow detecting bugs, vulnerabilities, and poorly written code.

6. References


Technical Risk Management and Decision Analysis — Introduction and Fundamental Principles

1. Overview I could not find a better way to start an article on Risk and Risk Management than by quoting the opening lines of Donald Lessard and Roger Miller’s 2001 paper that, briefly but lucidly, summarizes the nature of large engineering endeavours. It goes like this: This article leans heavily on three handbooks thatContinue reading “Technical Risk Management and Decision Analysis — Introduction and Fundamental Principles”

Complexity and Complex Systems From Life on Earth to the Universe: A Brief Introduction

1. Overview Dealing with complexity is an integral part of our lives, even if we do not realise it.  An organisation can be modelled as a complex system from the scale of megacorporations right down to the smallest teams. The architecture of software solutions can be equally complicated, and megaprojects and implementations are certainly involved.Continue reading “Complexity and Complex Systems From Life on Earth to the Universe: A Brief Introduction”

Book Review: Programming the Universe — A Quantum Computer Scientist Takes on the Cosmos

Synopsis Most physical theories adopt a mechanistic view when examining natural phenomena where any system can be modelled as a machine whose initial conditions and dynamics govern its future behaviour. In this book, Programming the Universe — A Computer Scientist Takes on the Cosmos, Professor Seth Lloyd proposes a radically different approach centred around aContinue reading “Book Review: Programming the Universe — A Quantum Computer Scientist Takes on the Cosmos”

From Abstract Concepts to Tangible Value: Software Architecture in Modern IT Systems

1. Overview Software design and architecture are two very elusive concepts; even Wikipedia’s entries (ref. architecture, design) are somewhat fuzzy and do not clearly distinguish between the two. The Agile manifesto’s statement on architecture and design is especially brief and raises more questions than answers. The most common definition of software architecture is as follows:Continue reading “From Abstract Concepts to Tangible Value: Software Architecture in Modern IT Systems”

Business Requirements and Stakeholder Management: An Essential Guide to Definition and Application in IT Projects

1. Overview The complexity of business requirements in IT projects has experienced exponential growth due to pressures by increasingly sophisticated client preferences, novel technologies, and fierce competition. Consider, for example, the case of financial payments. In the mid-80s, most payment transactions occurred inside bank branches, and only the biggest banks offered services on ATM orContinue reading “Business Requirements and Stakeholder Management: An Essential Guide to Definition and Application in IT Projects”

Human Groups as Complex Systems: Structure, Organization, Power Distribution, and Dynamics

1. Overview During most of the time we spend awake, we find ourselves an integral part of a large and complex system that we know very little about. We experience events that bewilder us and prove to us, time and again, how poor our abilities to predict future events or people’s reactions can be. OurContinue reading “Human Groups as Complex Systems: Structure, Organization, Power Distribution, and Dynamics”

Loading…

Something went wrong. Please refresh the page and/or try again.

Leave a Reply