Ward Cunningham told me about “technical debt” soon after he invented the phrase. He was working with fixed income traders who understood the financial uses of debt and wanted to explain to them why sometimes development went faster and sometimes it went slower.

‍

Since then “technical debt” has gone on to be the preferred explanation for development activities not directly resulting in features. “We need to pay down our technical debt.” [ed: auto complete suggested “technical debt”, which must be the modern definition of widespread usage]

‍

“That’s just an excuse for programmers to mess around.”

‍

“Technical debt” is widespread enough that there is backlash to it. “That’s just an excuse for programmers to mess around.” While a useful metaphor for communicating with some audiences, technical debt may have outlived its usefulness for communicating with non-technical audiences. It’s time for a replacement.

‍

Job To Be Done

Persuasive communication relies on being clear about:

• Who are we talking to?
• What do we want them to do?

‍

In this case we, the folks who can actually change the system, are communicating with those sponsoring or requesting or otherwise affected by software development. Our audience can’t write the code themselves (or they certainly wouldn’t put up with us), but they need new features; they need the system to behave differently than it does today.

‍

Our audience has oddly asymmetric capabilities. By relentlessly pressing for more features sooner, they can spoil software development over the long term. However, they can’t do anything to directly improve software development. They can mess it up, but they can’t fix it.

‍

What we’d like the audience to do is two-fold:

• Make priority and scope decisions that programmers don’t know enough to make. Business decisions create value when they say, “That’s enough of that, work on this other thing now.”
• Understand the distinction between working on the behavior of the system vs. working on the system’s structure. Some balance must be struck between investment in behavior and structure, a balance that will change as we progress and learn.

‍

Failure of “Technical Debt”

“Technical debt” is an excellent metaphor for communicating with those who understand the financial uses of debt (the real kind). However, “debt” comes with too much baggage to be useful when talking to a less prepared audience.

‍

Shame is big baggage. “Let me get this straight. You developed this system. You said it would be better. But you made so many dumb mistakes in the process that you’re now in debt and facing technical bankruptcy? And now you want to take 6 months to ‘pay it off’, during which I’ll see nothing changing and after which you’ll probably just run this whole scam all over again. Paying off technical debt sounds like vacation to me. I know, let’s just not.”

‍

It’s not what you say, it’s what they hear. Many business folks hear “mistakes”, “delay”, and “no progress” when they hear “technical debt”.

‍

“Friction”

We aren’t wrong in talking about “technical debt”. The structure really does need investment, either because our needs have outgrown our earlier decisions or our understanding has outgrown them. We need a metaphor more likely to encourage helpful behavior, like scope and priority decisions, and less likely to encourage damaging behavior, like shame and pressure.

I’ve begun using “friction” when talking to business folk. We want to reduce friction in development. I’m talking about the same activities, the same structural investments, as when I talked about “reducing technical debt”, but I’m using different language.

‍

What I like about the friction metaphor is it implies that we are continuing to move forward.

‍

In maintaining our relationship with business folks, it’s valuable to continue delivering features while we improve structure. We are moving forward. We are moving slower than we’d like, because of friction. We are proposing to reduce that friction. Once we do, we will be going faster with the same amount of effort.

‍

Give these words a try. See if everyone’s needs are better met as a result.

‍

Coda: Mechanical Orchard

The MO promise is replacing vintage systems, those whose friction has grown to infinity, with low-friction systems. We operate those systems to ensure that our incentives align with maintaining low friction indefinitely.

‍