For years, I have struggled to articulate technical debt to non-technical stakeholders. This struggle says something, given that technical debt makes an excellent metaphor in and of itself.
The concept explains that you incur a price for taking quality shortcuts in the code to get done quickly. But you don’t just pay for those shortcuts with more work later — you accrue interest.Save yourself an hour today with some copy pasta, and you’ll eventually pay for that decisions with many hours down the road.
So I say to interested, non-technical parties, “think of these shortcuts today as decisions upon which you pay interest down the line.” They typically squint at me a little and say, “yeah, I get it.” But I generally don’t think they get it. At least, not fully.
Lack of Concreteness
I think the reason for this tends to come from a lack of actual units. As a counterexample, think of explaining an auto loan to someone. “I’m going to loan you $30,000 to buy a car. With sales tax and interest factored in, you’ll pay me back over a 5 year period, and you’ll pay me about $36,000 in total.” Explained this way to a consumer, they get it. “Oh, I see. It’ll cost me about $6,000 if I want you to come up with that much cash on my behalf.” They can make an informed value decision.
But that falls flat for a project manager in a codebase. “Oh man, you don’t want us to squeeze this in by Friday. We’ll have to do terrible, unspeakable things in the code! We’ll create so much tech debt.”
“Uh, okay. That sounds ominous. What’s the cost?”
“What do you mean? There’s tech debt! It’ll be worse later when we fix it than if we do it correctly the first time.”
“Right, but how much worse? How much more time?”
“Well, you can’t exactly put a number to it, but much worse!”
And so and and so forth. I imagine that anyone reading can recall similar conversations from one end or the other (or maybe even both). Technical debt provides a phenomenal metaphor in the abstract. But when it comes to specifics, it tends to fizzle a bit.