Rest In Peace, Technical Debt. It’s Time To Forget Past Sins.

Everyone worries too much about “technical debt.” It’s not real. It’s just a slate of software projects that would have happened anyway. CIOs use debt use to protect budgets with categories everyone seems to accept. But the definition of technical debt should be retired and replaced with new projects that fix, modernize or replace applications already deployed. Or just avoid debt with smart development decisions even when there’s no time, money or talent. Or just forget about it altogether and focus on strategic alignment whatever that looks like in a dynamic company.

What is Technical Debt?

Let’s start with what everyone thinks about technical debt. For example, ProductPlan defines debt this way:

“Technical debt (also known as tech debt or code debt) describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored. In other words, it’s the result of prioritizing speedy delivery over perfect code.”

There are all kinds of technical debt, including:

“Code debt – Usually related to poor or speedy coding or not having applied appropriate design patterns.

Defect debt – Existing bugs, issues, and defects in the product.

Design debt – It is all the good design concepts or solutions that were skipped in order to reach a short-time goal quicker.

Requirement debt – Incurred during the identification, formalization, and implementation of requirements.

Test Automation debt – Refers to all of the simple and complex processes that are supposed to be automated but are not.

Test debt – This happens when the team starts to spend more time on test maintenance and less on creating tests to ensure the software is bug-free.

Architecture debt – Some architectural outline decisions incur technical debt, which can negatively impact the quality of a software project.

Documentation debt – This type of technical debt describes problems in documentation such as missing, inadequate, or incomplete papers.

Process debt – Usually generated when processes are poor or lacking altogether to handle defects, documentation, or even tests.”

According to TechTarget, there are different causes of debt:

“Poor software code quality

Ill-equipped IT leadership

Pandemic and remote work

No documentation

Job security through obscurity

Insufficient software testing”

Anything new here? Aren’t these lists perpetual? Don’t they apply to every technology project we undertake? Isn’t modernization a fact of application/product life? Don’t we replace applications that can no longer be modernized? Don’t we imagine new applications and products that can capture market share?

Debt in Practice

Let’s assume you design a house. You determine the size you want, the number of bedrooms and bathrooms you need, and the size and features of the kitchen you’d love to have. But you don’t have enough money for everything you want. What do you do? You build the house and you save enough money to change the house over some period of time.

You end up adding a bedroom and a bathroom and you redo the kitchen. It may take you several years to get all this work done, and by that time you might even want to redo the renovations you’ve already performed. When you bought the house should all of these projects, as well as some you never even imagined, be defined as acquisition debt? Could you have budgeted for the projects – some of which were unknown? Could you have priced them out, even though you know they wouldn’t happen until you owned the house for a few years, even as you redefined the projects on the fly?

Could you have anticipated problems with the house? Like a leaky roof, or a weak foundation? What about when the electrical system – which passed inspection when you occupied it – caused a fire? Or when the plumbing caused a leak? Could you have anticipated these problems? Could you have estimated the cost of fixing these problems even though you had no idea what they might be or when they might occur?

How about technical debt and financial debt?

“We take on technical debt for reasons similar to why we take on financial debt: we need something now (or very soon) that we don’t have the ‘cash’ to pay for in full. So we borrow to get what we need. With software, this generally means making coding or design decisions that are sub-optimal – or that we know will need to be addressed and updated in the future – in order to get what we want or need into production sooner.”

Doesn’t this analysis hold for just about everything? What doesn’t incur “debt” if debt’s defined around remediation, modernization and transformation?

Costs

As described by Ken Knapton in Forbes:

“Engineers spend 33% of their time dealing with technical debt. Multiple studies estimate the average organization wastes 23%-42% of their development time on technical debt. In those same studies, CIOs reported that 10%-20% of their new product technology budget is actually spent on resolving existing issues related to tech debt … Gartner predicts, ‘through 2023, I&O leaders who actively manage and reduce technical debt will achieve at least 50% faster service delivery times to the business.’”

These numbers are insane. If engineers spend 33% of their time fixing old problems (AKA technical debt) then the company will lose every competitive race it enters. More importantly, if you or I saw that number wouldn’t we ask some hard questions about why a third of the team was looking backwards – perhaps even at legacy system repair? And what about estimates that range from 23%-42%? Quite a gap, don’t you think? And how could anyone possibly know that “leaders who actively manage and reduce technical debt will achieve at least 50% faster service delivery times to the business”? At least?

What’s the distinction between technical debt – which is notoriously hard to estimate – and new project spending? Is it an easy distinction to make? Why are “old” applications flaws – which in many cases are unknown at the time of initial deployment – carried over to future budgets for long periods of time? If, for example, technical debt is partially “retired” by fixing known software problems, how does anyone know if the fixes themselves don’t create additional debt, perhaps even larger than the debt that required the fix? Doesn’t this feel like an endless spiral of insanity?

Pay Me Now or Pay Me Later?

Technical debt is alleged inevitable because developers don’t have enough time, money, talent, leadership, requirements – you name it – to do a good job. But what if they did? Does the phrase “pay me now or pay me later” resonate with anyone? Or is the creation of technical debt just planned shortsightedness?

Is the industry’s preoccupation with technical debt self-fulfilling?

There are tools – automated testing, quality engineering, debt estimators, modernization/end-of-life planning, etc. – that correct, improve and manage what everyone seems to think is inevitable no matter how hard a team works to minimize debt. Early investments generate long-term benefits – if there’s an insistence on even categorizing imperfection as debt.

Tatum Hunter has it exactly right: “stop talking about ‘technical debt’ … at best, it’s a way to avoid explaining your work … often, it’s an excuse for shipping bad code.”

A Late Retirement

The term “technical debt” should be retired. It’s too hard to understand, avoid, estimate, manage or eliminate especially given the nature of software and the inevitability of imperfect (and evolving) product development. Something that abstract has no right to exist as a real, imagined or budgetary development constraint. Let’s just admit that nothing is ever finished and no one should blame old development teams for debts no one could define, estimate or manage. All that’s necessary is a constantly evolving slate of projects designed to improve existing and create new applications that will all need to have their oil changed on a regular basis – until they don’t and they’re replaced with a newer model.

“Debt”?

What debt?