Why non-engineers should care about “Technical Debt”
I’ve ruminated before on technical debt, but I want to make this very explicit: this “tech debt” thing your engineers are complaining about will impact your customers in tangibly negative ways.
Asides, before I start: This is primarily aimed at non-software-developers. Technical Debt 101 is a great primer, but it’s lengthy. I have a single, small point to drive home here.
Update: Andrew pointed me to the article Bad code isn’t Technical Debt, it’s an unhedged Call Option, which is a more nuanced discussion built on a better analogy.
What is “technical debt?”
“Techincal debt” means that programmers have made some compromises in their software design. This could be due to any set of factors, but typically it’s because of a “move fast to get to an MVP” or “we must ship this in one week” mentality.
Software architecture is hard to wrap your head around if you’re not an engineer, so think of it as real architecture: you might build a structure using scaffolding, or with two-by-fours and duct tape, but you’re not going to let it live like that in the wild for long. If an engineering team says they won’t be ready to ship something in a week, or that they need to revisit some part of the software, this is why—it’s built from the software equivalent of scaffolding and duct tape.
Simply not taking technical debt is the best option. That’s clearly one strategy for avoiding an accumulation of debt.
But just as with real money, sometimes it is perfectly reasonable or necessary to take on debt. In those cases, the important thing is to ship, and then figure out how to prioritize paying back that debt. (Engineers will sometimes call that process “restructuring” or “refactoring” or some other abstract term.) How the team prioritizes paying it back is up to you or whoever’s in charge of the project’s short-term roadmap.
But why do we need to prioritize paying it back? Why can’t we just keep building new features?
Those scaffolding-and-duct-tape structures will have holes, and eventually you’ll want to add some weight to the structure and it will be just impossible. The same thing happens with software.
There are two reasons to pay it pack quickly, both of which will impact your customer experience.
Bugs
Code laden with tech debt will have bugs, for a huge number of reasons. Perhaps the programmer didn’t have time to consider all the edge cases in that feature or the implications of the change to the product. Or maybe the code was simply written to get a very minimum viable feature out into the wild on a deadline, and some parts just aren’t fully baked.
Either way, the end result is the same: bugs.
All software has bugs; software teams deal with them all the time.
But bugs due to an accumulation of tech debt will appear in a landslide: one or two at first, then a few more, and suddenly lots of your customers are unhappy because the software just _feels buggy; nobody goes a day without seeing some annoyance._
That is a priori bad for your company’s retention and referrals, and as dissatisfied customers complain on social media your image suffers.
Timelines
I’ll preface this by saying that software timelines are notoriously difficult to predict accurately. But that doesn’t affect my thesis here.
Once a codebase has accumulated enough tech debt, changing it becomes really hard. Engineers will find that the minimum viable code which was written in a rush months ago simply can’t support the feature you want to add, and so the debt gets paid back—but now it’s a surprise. It wasn’t planned for, and this feature is going to take two weeks longer than it should.
It’s usually impossible to see this wall before you hit it. So, your customers suffer because suddenly some features take longer to deliver. And the development team cannot predict which features those are.
Accumulating technical debt means that certain changes in the software will unexpectedly take much longer than they should have, and I argue that is also a priori bad.
Prioritization
I’ve alluded a few times now to the need to pay down tech debt quickly, rather than waiting months. Why?
The longer this duct-tape-and-wood remains in the project, the more features will depend on it. That means that when your team eventually has to replace it (see Timelines, above) the work will take much longer, and more parts of the software will be affected if any mistakes are made. Both of those are clearly situations to be avoided.
Summary
Taking technical debt is reasonable at times, but if you don’t prioritize paying it back (listen to your engineers!) your customers will start to notice and suffer. And fixing that is going to be a whole lot harder later than it is now.