Note: This post borrows heavily from Eric Normand's podcast How far can we stretch technical debt?. I am heavily indebted to him for the ideas in this post.
The Misunderstood Concept of Technical Debt
Technical debt is an integral part of software development. It's the cost incurred from opting for short-term, quick-fix solutions over the ideal, efficient, and often more time-consuming code or infrastructure. The trade-off seems lucrative initially, but the accumulation of these shortcuts eventually slows down future development, making it costly in the long term.
Most engineers grasp the concept of technical debt intuitively. They understand its impact on development speed, and the resource commitment it demands for repayment. However, those outside the realm of software development often misconstrue how technical debt works, assuming it parallels financial debt.
The Similarities
There is one parallel between financial and technical debt that is accurate. Both require additional resources to maintain compared to their optimal alternatives. Similar to making debt payments rather than investing in growth, maintaining poorly written code or infrastructure consumes more time and effort than if it were written optimally. Thus, resources get diverted from productive uses, creating waste.
The Differences
Despite this similarity, technical debt differs from financial debt in several fundamental ways. I'll use investing in a restaurant as a running example.
1. The Freedom to Discard
If you build a flawed system in a fraction of the ideal time, say 10 days instead of 30, and later discover it's a non-starter, you can discard it without consequences. This isn't possible with financial debt. If your restaurant venture fails, the debt doesn't disappear; you still need to repay the loan. The best you can do is sell off your assets to offset the loss. But with software? We can delete code without any financial penalty.
2. You Can't Pay Down the Principal
Now suppose you build a system in 10 days that ideally requires 30 days, and it turns out to be a winning idea. To perfect it, you still have to invest the full 30 days, as the initial 10 days don't count towards this.1 Unlike financial debt, where early repayments reduce the overall burden, with tech debt you can't expedite the process or pay it off in installments. This unique characteristic of tech debt makes it a formidable opponent — it's harder to eliminate than financial debt.
3. The Difficulty of Quantification
Finally, tech debt lacks the clear-cut metrics associated with financial debt. There's no universally accepted way to calculate the cost or ROI of rebuilding a system. It remains an estimation game, further separating tech debt from its financial analogue. You never know exactly how much it will cost to pay it down.
Tech Debt Reimagined: A Better Analogy
Imagine that you are running a restaurant with subpar tables. Imagine tables that are slightly too small, wobble annoyingly, have screws that are constantly coming loose, and, worst of all, annoy your customers. Maybe you chose them because they were a bargain, or you were uncertain about the restaurant's future, or perhaps you just didn't have enough experience to make a better purchase at the time.
This is what technical debt feels like. You can't return the tables for a refund to purchase better tables. You're stuck with them until you decide to invest in superior replacements. You know there is something wrong with the status quo, but just like repaying technical debt, it's unclear whether new tables will generate more revenue or if the time saved on table maintenance will translate into increased profits. You have to make a guesstimate — or make an opinionated choice for your company regardless of the dollars.
The True Meaning of Technical Debt
Acquiring technical debt is not like acquiring financial debt but rather like managing an asset with high maintenance costs. The resolution of technical debt involves building or buying a new, more efficient asset to replace the old one—a task far more complex than merely settling financial debt.
In the world of software development, accepting technical debt is often a strategic, sometimes unavoidable, decision, made with a clear understanding of the long-term implications. If there might not be a tomorrow for this product, or even for the company, it can be a smart trade, but remember that today's expedient solutions are tomorrow's inefficiency.
In my experience, migrating working code to a new system is usually about as hard as writing new code from scratch.
↩