“Technical debt” is one of those terms in the software industry that is overused to the point of becoming meaningless. It’s very common for engineers to overlook the ‘debt’ metaphor, and think of technical debt simply as something bad. Their perception is that tech debt is a ‘short cut’ or choosing convenience over doing things the right way (though that is also true sometimes).
So why is it called a ‘debt’? Taking on a debt implies a resource constraint. But which resource? And who is constrained?
Typically, the managers. And the resource that we are perpetually short of is developer capacity. This is the currency that helps managers deliver on company or business expectations. This is why managers are always obsessing over capacity through activities like quarterly planning, estimations, story points, budgeting, tracking vacations and absences, etcetera. Any ad-hoc feature request goes through intense negotiations, impact-effort analysis, or… haggling, basically. The amount of work to be done is always more than the capacity available, and this is why managers suffer from a scarcity mindset. (Btw this explains the universal exuberance towards AI in management circles. Because it’s like suddenly finding out that you are not poor anymore!)
So this is why managers have to opt for the trade-off of taking on technical debt. And the debt metaphor here is really apt. For example, I need a house for my family today, but I don’t have enough money. So the simple trade-off is I must take on debt to be able to acquire the thing, i.e. the house, that I care about in the present moment.
The same applies to technical debt. I need to deliver a project that will require a certain amount of developer time or capacity to be able to be done in a way that is fully architecturally correct. But I am short of time. So I make the trade-off that the expected payoff from delivering the project on time is more valuable than the cost of taking on tech debt.
So, is tech debt always good?
It depends. Because just like a financial debt, a tech debt can go spectacularly wrong.
It felt nice in the moment to buy that car on a loan. But now it means I can’t afford early retirement. Tech debt is similarly risky.
Taking on tech debt gives us an advantage in shipping features that help the business. But like a real debt, it weighs us down. It shows up on our balance sheet. And like Ward Cunningham’s original framing, we need to pay it back soon or we have to pay interest. What was supposed to be leverage that helps quickly move the business forward may slow down future progress, create a ton of cleanup work and suck all of your team’s capacity.
This is why engineers are apprehensive about the idea of tech debt just like the folks in r/Bogleheads are horrified by a 3x leverage ETF. You have to be careful when taking on technical debt, just like with monetary debt.