Actually, tech debt does matter.
Special thanks to Ian White who reviewed this prior to publication
Back in July, Tatum Hunter published a thoughtful piece with BuiltIn about why the term “technical debt” should be retired. In it, she dissects the problems with the term in today’s techno sphere. Principally, that it’s too vague to be useful and is often co-opted to obfuscate subpar technology under the guise of paying off the debt later. However, I feel her article does some damage to an ongoing fight I’ve seen firsthand to add finance to technology and help technology align to business better.
First, I should tell you that I am often leery of pushing too hard to mingle business and technology. I have a genuine love of the early techies and the philosophies they applied to meld art and science into something grander. Before I jump into the business rabbit hole, I’ll plug “The Innovators” by Walter Isaacson as the premiere introductory tech history book. Equally, I’d suggest reviewing the Electronic Frontier Foundation to see where dystopia meets modern corporate America.
Now on to the main event. I should start this retort by mentioning that, at the very end of her voluminous work, Hunter actually ends up undercutting the premise of her entire argument. In fact, she essentially throws her hands up and claims that perhaps removing the term “tech debt” from our silicon vernacular isn’t even possible: “All in all, it’s tough to argue that technical debt isn’t real. Inefficient or outdated technologies can bring companies to their knees.” On this point, Hunter and I agree.
However, on her way there, Hunter lays out a series of points to discredit tech debt as a term useful in the industry. There are chiefly three points that merited most discussion:
- The term “tech debt” is too vague
- Agile devops has debased the real value of tech debt
- Tech debt isn’t always applicable
Hunter spends a significant amount of time leveraging a piece by 4Degress founder David Vandegrift. Vandegrift argues the term has been so misapplied by everyone from engineer to accountant that it’s not really clear what someone means when they use it now. Engineers use it to cover bad code, managers use it to avoid telling individual contributors that there ideas are bad (“It would create tech debt!”) and so on. I agree. Where I don’t agree, is that the term is somehow not useful for that reason. On the contrary, we need to use it more. The real problem is we are not disciplined in how we use it.
Tech debt matters because debt matters.
Let’s quickly switch to a metaphor I used in a recent piece on tech debt. Airlines regularly keep liabilities on their books for opex they expect to have in the future. For example, you’ll see line items for plane maintenance expenses or for terminal upkeep or even whole plane replacements at end of life. Airlines have life and death right in their face all the time and as a result, they must keep clear account of the future debt they’ll pay for a real asset in the world today. Would you want to fly for an airline that struggled to define what “plane maintenance debt” should be? Or worse, would you want to fly them if they simply removed discussion of maintenance debt altogether because it was too hard to define? The metaphor seems silly but it’s absolutely accurate. Today managers and senior engineers simply don’t force real tech debt conversations or the people having them aren’t sufficiently knowledgeable in either finance or technology to a depth to allow them to quantify the dollar value of their tech decisions. That’s not an excuse to be lazy, it’s a mandate to get better.
The second part of Vandegrift’s argument discusses the “20% time” many agile organizations book routinely in each sprint to cover tech debt. Hunter emphasizes the point that it’s basically lost time since it’s in every sprint and often, not value adding. I argue that paying off debt is absolutely value adding if that’s what you’re doing. Real debt is paid off and as a result, the company has fewer financial obligations, freeing capital up to be productive. Would anyone claim a principal payment on corporate bonds aren’t value adding to the company? No. The difference is when you pay down bonds, the value is easily palpable. The problem with tech debt is often, there’s no correlation between the debt and the value it’s adding to the company. Blanket 20% time for tech debt is perhaps more useful than never paying off tech debt but it must actually pay off real debt, not manufacture tasks to be completed instead of feature development.
Don’t try to track every piece of tech debt. Focus on what matters.
Which brings me to the last part of Hunter’s argument: not all tech debt matters! Some tech simply limps along just fine until it’s killed. To that, I’d say I agree with one minor distinction: that’s not tech debt. Bridging my metaphors again, if you had three credit cards and elected to donate $10 to a charity, you’ve done nothing to pay off your debt. It’s admirable, sure, but you’re not defining your debt correctly so you paid money out but not against debt. Our struggle to focus on what’s really debt doesn’t mean we don’t have debt. It simply means we do make mistakes like Hunter fears where we work on the wrong things thinking we’re adding value. Again, this comes back to a fundamental lack of discipline in scoping and quantifying technical debt.
Tech debt should be defined by whether or not it is a liability to the company. If it is a liability, then the cost to repay it and the timeline on which it must be repaid must also be defined. This isn’t new. Accounting has done this for insurance, manufacturing, and many more industries. Properly accounting for the liabilities your company has to pay isn’t impossible, it’s responsible.
