There's no such thing as tech debt
There's no such thing as tech debt
A different, better way to convince your stakeholders to fund tech improvements
In the weeks after Elon Musk took Twitter private, debate threads sprang up about "tech debt":
First, let’s talk about what folks are really doing when they use the phrase “tech debt”, why it’s a crappy, misleading metaphor, and why it’ll almost never get you what you’re after: permission to fix something. Then I’ll share a simple way to have a more productive conversation with your stakeholders.
Ward Cunningham introduced the metaphor in 1992. He meant well, but the metaphor only makes sense to the people who already understand software engineering, and the cost of not caring for your code. When you’re talking to somebody who doesn’t get it - especially a finance-minded person - telling them it’s “like debt” is only going to hurt your case. I banned the phrase years ago because it doesn’t make things any more clear to anyone in the conversation, and it doesn’t get us any closer to making any decisions. Engineer-to-engineer we don’t need to use the metaphor because we can just talk about the specific technical problem and how to solve it. Engineer-to-non-engineer, calling it “debt” is confusing at best, and engineers are notorious for the bad habits it encourages.
First, it’s a way for engineers to try to avoid accountability and push it back onto “the business”:
Have you found yourself saying this: “We told the product manager/vp/whomever if we take these shortcuts it’ll get the ship date they want, but at a cost. They accepted it, and now the bill is coming due!” You warned them. This sets us noble engineers to be Cassandra, the princess in Greek mythology who was cursed to know the future but never be believed by anyone. We are all-knowing but helpless, which means when things go well it’s because everyone listened to us, but when things go south it’s because we were ignored. All of the credit with none of the blame! Reality is never that clean. The whole team - engineers, product, stakeholders - are fumbling through decisions together on the fly, with imperfect information. Intuition might say “hacking this thing together will bite us down the road”, but what “bite” means in that moment is never as clear as an interest rate or an amortization schedule. Sometimes it ends up being unsightly but good enough, forever. Plenty of times, the downsides of an implementation decision don’t become clear until long after the fact. It’s the decision we didn’t realize we were making:
But we don’t take on debt by accident. Or at least, if you’re trying to translate engineer-speak to a finance person, they sure don’t take on debt by accident. The CFO doesn’t come in one morning and go “oh crap, I thought I paid cash for this but it looks like it’s been collecting interest the whole time.” The metaphor doesn’t make any sense. So what should we do instead? First, stop acting like business decisions and engineering decisions are separate things. We engineers are here to use technology to make the business work. We are part of the business. All decisions are business decisions, so own the decisions, and own the results. Even - especially - when the results are only now becoming clear. Acknowledge software engineering is not like accounting, it cannot be made to be like accounting, and it involves a lot of uncertainty we have to deal with as it comes.
“But it’s not an accident, I’ve been sounding the alarm and they just won’t listen!” If an accountant said “Hey, we have this debt payment coming due”, your leaders would not roll their eyes and go “ugh, these accountants with their ‘debt’ again.” The problem isn’t that they aren’t listening, it’s that you’re not giving them actionable information. The difference is debt, like cash, is measurable and fungible. Whether it’s a credit card or a corporate bond, once it’s on the balance sheet it doesn’t matter what you bought with it. There’s a simple math relationship between the cash you use to pay it back and the remaining debt burden, and any dollar spent paying back any debt has the same effect. This is how much debt I have, this is how much cash I have. I can make decisions with that. Is this true for engineering hours? If I want to reduce my “tech debt” and I am willing to pay it down by 110 engineering hours, will that get me exactly 10% less tech debt than if I only spend 100? No. “Tech debt” is the title at the top of a list of specific defects and shortcomings in the system. Each one is unique, it has a completely different set of costs and risks, and potential mitigations and solutions. Why is the list titled “Tech debt” and not “Specific defects and shortcomings in the system”? See above on avoiding accountability.
When we call it “tech debt” and say it “slows us down”, we’re not holding ourselves to be precise. This makes it really easy to do something I see engineers do all the time, and I was guilty of early in my career too: “tech debt” becomes the parts of the system we would make more elegant if we had time to do them over. It’s easy to look at a finished solution and imagine how we could do it better, especially if the business problems we’re working on aren’t very technically interesting. We start getting frustrated by the gap between how the system is and how awesome it could be, and we start saying it’s “slowing us down”. But in truth, we’re just feeling bored and dissatisfied with the aesthetics of the status quo. “It could be better” is always true, and so it is also useless and irrelevant. Is it good enough is a useful question, because it has a yes or no answer.
“Is it good enough?” against what criteria? Our business goals, of course! And this is how we change a useless conversation about “technical debt” into a useful conversation that gets engineering and stakeholders to both agree on the right investments: make sure you have a clear, measurable list of the business goals you are being asked to achieve. If you cannot achieve them, then explain why:
We cannot deliver that feature this year with the people we have, because we currently spend 8 hours a week on these manual tasks we neglected to automate. If we spend 200 engineer-hours building the automation, that will recover the 8 hours a week or 200 hours this year and 400 each year after, but in the immediate term that will delay our schedule by approximately 4 weeks.
Now that’s an accounting we can use to make decisions. We can all agree on the facts and discuss the pros and cons. It doesn’t get into any useless details about architecture or whatever “-ility” we wish our system had more of. Here’s some other examples:
“The system can only serve X load before Y tangible impact occurs. If our goal is to serve Z load by D date, we have to spend N engineering hours to add that capacity.”
“The system has X security vulnerability. If it is exploited, the cost of the impact would be Y in real terms and Z in reputation and trust. An attacker would need to achieve Foo to be able to exploit it. It will cost us N engineering hours to close the gap.”
TL;DR - don’t say “tech debt”, work backwards from your business goals and if you can’t achieve any of them, just say the actual specific reason why and what you need to fix that specific reason.