Engineering Excellence

Share this post

There's no such thing as tech debt

rexm.substack.com

There's no such thing as tech debt

A different, better way to convince your stakeholders to fund tech improvements

Rex Morgan
Nov 20, 2022
Share this post

There's no such thing as tech debt

rexm.substack.com

In the weeks after Elon Musk took Twitter private, debate threads sprang up about "tech debt":

Twitter avatar for @copyconstruct
Cindy Sridharan @copyconstruct
Tech Debt is one of those things that make sense to engineering, but to leadership it sounds like “we’ve created a mess over the years that slowed the product, we did nothing to fix it, and now we need to spend *even more* time and people on fixing it”. Not a winning argument.
Image
5:54 PM ∙ Nov 14, 2022
1,312Likes153Retweets

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.

Thanks for reading Engineering Excellence! Subscribe for free to receive new posts and support my work.

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”:

Twitter avatar for @elchefe
Tim Banks: Principal VibeOps Engineer @elchefe
Technical debt is almost always a business decision, not an engineering one. As such, the notion that “leadership” wouldn’t understand what technical debt is at a tech company seems like a really big fucking reach.
Twitter avatar for @copyconstruct
Cindy Sridharan @copyconstruct
Tech Debt is one of those things that make sense to engineering, but to leadership it sounds like “we’ve created a mess over the years that slowed the product, we did nothing to fix it, and now we need to spend *even more* time and people on fixing it”. Not a winning argument. https://t.co/KXRSC1Qoen
10:45 PM ∙ Nov 14, 2022
734Likes54Retweets

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:

Twitter avatar for @rexm
Rex Morgan @rexm
What is software architecture? It is the sum of all the decisions made about the system. The question is often whether those decisions were made deliberately!
Twitter avatar for @thewizardlucas
Lucas, The Wizard (he/him) @thewizardlucas
Software architecture always exists, regardless of whether you chose to architect the code in a particular way. If you don't architect your software on purpose, luck will architect it for you.
2:09 PM ∙ Sep 12, 2022
4Likes1Retweet

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.

Twitter avatar for @polotek
Marco Rogers @polotek
How much tech debt do we have? "A lot!" But like how much? Gimme a number. "Well it's not a number per se..." But you're sure it's a problem? "Definitely. Our velocity is reduced!" How much? "Well it's not really a number..." So how do you know? "Jira tickets and vibes."
3:43 AM ∙ Nov 15, 2022
127Likes12Retweets
Twitter avatar for @polotek
Marco Rogers @polotek
"How much financial debt do we have?" <extremely specific number, down to the dollar> When will we go bankrupt? <projected to within a month> How many layoffs? <numerical estimate based on projected expense targets> How do we decide who? "Lines of code and vibes"
3:56 AM ∙ Nov 15, 2022
53Likes2Retweets

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.

Thanks for reading Engineering Excellence! Subscribe for free to receive new posts and support my work.

Share this post

There's no such thing as tech debt

rexm.substack.com
Comments

Ready for more?

© 2023 Rex Morgan
Privacy ∙ Terms ∙ Collection notice
Start WritingGet the app
Substack is the home for great writing