In this post, I want to talk a little bit about technical debt. In a recent conversation I had with one of our engineers, we sort of inadvertently enumerated some of the more pressing technical debts we have off top of our heads in our current infrastructure, which, now that I think about it, is quite a lot. But what is “technical debt”, really?
Techopedia defines it as “a programming concept that reflects the extra work required when developers choose an easy short-term solution over the best long-term approach. Like financial debt, it incurs interest in the form of increased maintenance costs and complexity over time.” I think I can get behind this definition. And while there are good debts and bad debts in finance, I think technical debt is mostly associated with a feeling of frustration, or resignation. I don’t think I’ve ever come across a situation where technical debt is being talked about in light of something akin to “good debt”. It’s always “bad code”, “bad design”, “bad choice of framework”, etc. But I think this association is a little precarious. For developers, they might assume that the previous developers were just rubbish at their job without considering the constraints and tradeoffs made at that time. Product people might think that developers were just using tech debt as an excuse to extend the delivery schedule to a month just so they can play around with the stuff that they care about more than the feature they’re being asked to do. Engineering leaders might assume that their developers are spending too much time debating on patterns, and differing opinions on the correct way of doing things instead of agreeing on tradeoffs and carrying on.
Another more interesting trap with that association is that if we just write good code, then there shouldn’t be any tech debt. But in reality, even a well-engineered solution will eventually become tech debt over time, especially when the original implementers leave the company, bringing that undocumented, contextual knowledge with them. And things like changing technologies, abandoned open source solutions, software license changes, leadership changes, budget changes, even bit rot, can render an almost-perfect implementation a tech debt in no time.
One common thing I observed teams do to mitigate tech debt is to conduct tech debt-only sprints, or tech debt hackathons. While good-intentioned and practical, it sometimes encourages a culture of postponing good design upfront just to honor the initial, usually very tight schedule, instead of negotiating and meeting in the middle. And while I’ve experienced some success with this approach, refactors and maintenance work are rarely rewarded. They’re invisible, thankless, boring, and soul-crushing, especially if it’s not your own. Now, I’m speaking in general terms here; I know a bunch of people who prefer maintenance work than endless pumping of new features. And more power to them. But I think this is not uncommon. Companies rarely reward tech debt maintenance, especially when there are a lot of initiatives and new features that drives the business forward.
So how to deal with it then? Unfortunately, I don’t really have a defined answer to this. At Alphaus, I advise our engineers to include tech debt (if there’s a need to deal with it) in their estimations, and think of it as just that: part of the solution. I don’t encourage separate, isolated efforts just to tackle tech debt, although there are times when we just admit defeat, deal with it, and then move on. I like to think of it as how we deal with financial debt, really; we pay in chunks monthly until it’s fully paid. It’s just part of the monthly budget. And occasionally, you get some extra cash and so you pay a little bit more.
On a more systematic approach though, tech debt is really part and parcel of software development, at least in the current state of things. There are schedules to be met, and customer requests to be fulfilled. Whatever method(s) one employ to formalize tech debt management, which I think really depends on the company size, some points need to be considered:
- Metrics for visibility and understanding of systems;
- Ownership at the higher level;
- Alignment (and agreement) on the value to the business if a specific tech debt is addressed;
- Understanding of cost and associated risks when not addressed; and
- Metrics to measure success (or completion).