Technical debt is one of those touchy subjects that tend to make folks a bit twitchy. Depending on who you ask it is either a powerful strategic tool or just a fancy term for bad practices and laziness. The truth is, of course, nuanced.
There is certainly no shortage of organizations that play fast-and-loose with the term "technical debt". Through either ignorance or willful self-deception, they apply this label to tech that is simply bad. They have no intention of ever addressing this debt so calling it such is pure euphemism.
But when it's done right, tech debt can indeed by a powerful strategy. Think of it like borrowing against your future self. Startups who are striving to hit PMF (product market fit) do this a lot, for instance. You need to ship some code and doing it right will take an extra month. You might be in a precarious financial position and would rather push the burden of that extra month to a future version of you who has a bit more wiggle-room. And in the highly likely event that the startup either pivots or folds, it's like declaring bankruptcy on your tech debt. There is nothing wrong with that approach at all; in fact, the entire concept of the lean startup is based on that, through the proliferation of MVPs.
This article isn't about either of those two stories though. It's about mature enterprises who take a cyclical view of tech debt, tying it directly to their bottom line performance. When times are good, the corporate purse-strings are loosened. Consultants, specialists, and senior developers are brought in and high standards rule the land. But good years are followed by bad and usher in very different policies. Now the name of the game is cost reduction and there is no money to pay for all the specialists anymore.
And that's when someone has a brilliant idea: let's run up some technical debt! We'll do it deliberately and we'll do it strategically. During the lean years we replace the senior team with a junior team. Yes, productivity will go down. And yes, the amount of bad code will go up. But we will just fix that when the wheel of fortune makes its next rotation and we can bring the experts back. The theory goes like this:
The problem is that this has worked as advertised exactly zero times. And yet it keeps being deployed as a corporate strategy. It's time we stop the madness. Because what actually happens, at best, is this:
So what happened here? A couple things:
- Technical debt, by its very nature, tends to not actually be documented. There's no spreadsheet titled "Crap to Fix". So the hunt for poor practices often takes as long as the remediation itself.
- During this hunt/remediation process, the resurrected senior developers are also expected to start producing on a whole new set of deliverables; it's a very rare organization indeed that sets aside a specific block of time just to remediate tech debt. This creates an effect similar to a person receiving a fat bonus check only to discover that half has been taken out for taxes—the tech debt has now come due and begins eating away at the productivity of the senior developers. And frequent gear changes and distraction ensure that the whole is less than the sum of its parts, that developers virtually never have 8 productive hours during a workday.
But if you look at the second graph, it doesn't actually seem all that bad. Sure the "theory" graph is a bit more up-and-to-the-right than the reality, but not by that much. But there's actually something even more nefarious that is not shown on the above chart, and that is the behavior and expectations of users during the period of accumulating tech debt. Bad code rarely produces good outcomes. Sure, you might be able to get away with it for a month or two without anyone noticing, but within a couple cycles it's virtually guaranteed that users will start having a worse experience. And when that happens the inevitable result is a drop in adoption. It's extremely hard to win back the same cohort of users (which is precisely who you have in a corporate context) once they have become disillusioned with your applications. And if the success of tech initiatives is measured by adoption, that means you will have a tough time climbing back to your peak of success. It's like the stock market: if you lose 50% and then gain 50%, you aren't back to where you started. The ascent is much harder than the descent.
"OK, but budget realities have to be taken into account," I hear you saying. No arguments there. At least not today, although I have argued in the past that tech, particularly business intelligence, needs to pay for itself. But stipulating that a cost reduction is needed is not the same as stipulating that tech debt is needed. Let's say you are a director who has been handed down a 50% cost-cutting mandate and currently have a team of 10 senior developers. Rather than switching to a team of 10 junior developers who are half the hourly cost of the seniors, I would instead propose cutting the existing development staff by 5 people during the lean periods.
The advantage to this approach is that, while progress slows down during the lean times (which would happen with a junior team in any event) tech debt does not go up. The above problems are simply never encountered.
I know I am not proposing anything revolutionary here. This last approach is so obvious that there is no need to belabor its merits. You go fast on a highway and pump the breaks when you encounter a small road; you don't ditch your rear two tires. For those reading this anticlimactic conclusion and rolling their eyes, I apologize and you are dismissed.
But the reason this article had to be written is because there are still a great many enterprises who stubbornly cling to the deliberate cyclical tech debt approach, contrary to all logic, evidence, and history. And I am very specifically calling out enterprises as opposed to SMBs. It seems that the perfect storm to sell the concept of cyclical tech debt can only occur within the type of bureaucracy where business outcomes tend to be more disconnected from decision-makers. I urge enterprises to align their various technical departments on both the strategies and incentives needed to avoid disastrous results for customers. Because, at the end of the day, that is who we are all here to serve.
