The term "technical debt" is bad, and we should feel bad

How to actually get important work done, without name-calling

Tech debt means multiple things to multiple people. I wish the term had never been invented. I imagine it has been re-invented a thousand times in conversations like this:

DEVELOPER: We need to go back and fix our architecture

FOUNDER: Architecture? like a building? But we have a 1.0 shipped and making money

Yeah, but we aren’t going to be able to ship version 2.0 in this state, it will take so long and will likely not work.

But you said you knew how to build things well; your whole thing when we hired you was that you build things the right way once.

That doesn’t sound like me. Anyway, yeah, well I didn’t expect all these constraints to be thrown at me like they did; it was really hard to ship something for the long-term, when it needs to work in the short-term, and we don’t know everything yet.

So again, why do you need to rebuild everything?

We don’t, not everything, its just that our system is writing checks that it can’t cash…... You know when you overextend yourself and then have to calm down and rest? Like when you go into debt?

Oh yeah, I know about that. I have 4 mortgages on my house, it is how we got money to hire you for the Version 1.0.

Yeah, well its like that - we need to pay off some of the debt.

OK, I guess.

Technical Debt Projects Do Not Get Love

If you separate technical debt from other work, then you have narrowed your chance of ever actually working on it.

This picture does a better job explaining part of the dynamic:

The Problem with Technical Debt

There are other, more complex, reasons that technical debt projects won’t get worked on.

First, let’s be clear, projects that are:

• well-understood

• have executive sponsorship

• can be justified with a business case

• come from a customer

Have a higher chance of being worked on. Technical debt projects don’t meet these criteria often because they:

• make it look like you didn’t do a good job building things

• can be hard to explain, and it has to be explained by developers

• start out as grassroots by the people with the most low-level knowledge of how the code works (programmers, support)

• are confusing, because to product management they feel constant:

  • a bad developer always wants to upgrade the system to a newer, more attractive technology , for selfish reasons - work is more interesting and it might be better for your career

  • a good developer always wants to upgrade the system, for valid reasons locally that might not be valid globally (i.e. the system would run better if rewritten in Rust, but it doesn’t make sense for the business to spend the money to do so)

• are not started by customers explicitly

Add all these factors together, and you’ll find that “technical debt projects” have a harder time getting started and completed.

Technical “Debt”

The term technical debt is a failure of imagination. Sure, it is an accurate way to describe something that happens from time to time:

You:

• don’t have time to do it the Right Way

• need to ship something quickly

• build something that works for now, with the present knowledge that it isn’t the best solution for the future

• were exactly right about the future, so when it arrives you now need to go build it the way you wanted to in the first place

The problem is that once the future arrives, in hindsight, most technical decisions look like technical debt. This is why people call a payroll system that has generated hundreds of millions of dollars in revenue for decades a legacy system, riddled with technical debt.

These are more common situations:

You:

• don’t have time to understand the problem

• need to ship something quickly

• build something that works OK now

• the future arrives and it needs a better solution

You:

• understand the problem well

• need to ship something

• build something that works well now

• the future arrives and it needs a better solution

You:

• understand the problem sorta-kinda-maybe

• need to ship something

• build something you aren’t sure is going to work (like a startup’s product)

• it works enough for the future to arrive

• the future arrives and it needs a better solution

In all cases, in hindsight, the problem and solution seem obvious and like you made an intentional debt decision in the past. Or someone did. But guess what: they didn’t.

The World Around Your System is Changing

“the future arrives and it needs a better solution” can be a long list of things:

• it is now harder to find good COBOL programmers

• it is cost prohibitive to host it the way it was built, or find people to keep it running

• it is no longer legal to run the system the way we do, or for it to make the decisions in the way it does

• the system does not scale - worked fine for awhile, then OK for awhile, then we fixed something, but now there is visible smoke coming out of the back during business hours

• the system works well for one domain, but the business wants it to work for another domain

• One of the system’s big assumptions is wrong:

  • Years can be represented in two digits

  • Flights only depart from their gate once

  • Daylight Savings Time always starts around spring and continues until fall

  • Cars only having one engine at a time

  • A street number in an address will never be 0

• The vendor of one of the technologies has raised their prices so much that you have to rebuild without them or go out of business and change your identity

• One of the key open-source components we rely on has a maintainer that wishes to afford a reasonable lifestyle that includes not being able to see his kitchen from his bathroom

• etc. (this list is essentially infinite)

Some uplifting metaphors

Think of it this way: every relationship in your life is actively decaying. If you don’t make an effort to spend time with your wife or you kids or your friends, they drift away. Everyone you stop calling drifts away faster. You are losing everyone that you don’t fight not to lose. Would you call this relationship debt?

If you own a home, the house is decaying around you and trying to kill or bankrupt you. You need to spend money on simple things like new paint and cleaning, but also on large things like replacing plumbing, resealing your deck, and fixing the driveway where the tree roots have pushed it up. Is this debt?

Likewise, all computer systems are decaying, becoming more irrelevant and less functional as the world around them changes or what is required of them shifts, drifts, expands, or contracts.

This isn’t debt, its entropy.

Your fight is not with debt, it is with chaos. Just like you need to be making an effort towards the relationships that matter in your life and fixing things in your house, you need to constantly be making an effort to keep your systems working as conditions change. This should be part of your normal backlog, and not a separate thing.

Technical Debt Leadership

As technical leaders, we need to treat technical debt as a part of ongoing work, and not separate from it. By isolating it we bring a spotlight to something that is just a reality in our field, and a bit hard to explain to those slightly outside it. You need to constantly upgrade your infrastructure and architecture for the future, with a clear understanding of the present needs. That’s it, that is all there is. And this has better ways of being explained than “technical debt”.

Some examples:

• When you estimate building Version 2.0, you include changes to frameworks and infrastructure that are actively causing issues or will in the near future.

• We need to use this new framework because its hard to make changes now, and we need to be able to derisk the components breaking each other, and we need to ship faster.

• We need to upgrade our infrastructure to handle the 30% estimated new customers without increasing hosting costs.

• When we fix this bug, we should work on the design to ferret out the assumption that caused this bug, not just fix this instance.

And when you need big things (like a weekend away with your family or a new central air conditional unit) they should be tied to business goals not treated as a separate technical debt project.

Sometimes you need to express this as an objectives that are always true. The justification of these changes is not always new-new functionality, its just keeping on as you are now:

• Have a happy marriage: I’d like to continue to be married, so let’s spend some more time together.

• Live in a safe home: I’d like to sit at the dining room table and not have rain get on me this winter, so let’s fix the roof now.

• Have a system that can be changed: Changing the system for one new business rule should not risk breaking other parts of the system.

• Having a system that customers can depend on: If our reliability decreases another 10% we will lose customers and reputation.

You aren’t paying down a debt, you did not take on debt. You built things the best you could with what you knew and could do then, and now you need to improve the system with what you know now, to support your business goals. That’s it.