warpedvisions.org

I don’t like the term technical debt. We mostly use it without thinking, and it’s often the wrong way to frame the value of our software designs. Most of the time we’re being dishonest when we call our decisions debt, and unless we're planning out the general long term costs of our approach, it's not debt at all.

With financial debt, money is mostly money, regardless of the source. The terms of a loan are known up front when we borrow money, and those terms may or may not be satisfactory. Any decision to borrow is based on a known commodity, and on the need and the terms, both compared with the gains. Taking on debt, at least in business, is an informed and unsurprising proposition. Debt is often a rational choice for a business too, if the risk is low and the return is favourable. It’s rare for a company’s investors to allow a business to take on financial debt that isn’t clearly understood.

With technical debt, both the commodity and the terms can be fuzzy. What’s being borrowed isn’t always known, and the risk/reward isn’t always easy to measure. If technical decisions are a commodity, they can be a volatile one. If the cost of those decisions are the terms, then they’re not always agreed upon ahead of time. Taking on any debt without knowing both the values of the commodities and the cost of the terms makes it impossible to think about the proposition clearly.

At best, we treat software technical debt like consumer debt, where we blissfully ignore the commodity and the terms of our choices, focusing only on our immediate need. At worst, we label our poor technical decisions debt (especially our predecessor’s). It’s a lazy phrase, a cop-out, and is a costly way of doing business.

There is a place for actual technical debt in software projects, but it needs to be informed and planned. For example, it may not make sense to invest in a fully scaled system before proving out a concept. Starting down a simpler path can be the better choice, as you can reduce the overall risk with a moderately increased cost. That simpler path has a future cost, of course, but it can be a rational decision to defer the full cost of the solution until you know more about the features and fit to the market. Taking a split risk in approach can be good for the business, but the risk and terms need to be part of your planning.

Technical debt that rears its head unexpectedly, on the other hand, isn’t debt, it’s regret. We often regret our past decisions, as they can be very costly and inconvenient. But if we treat our remorse as debt, then we’re admitting that we’re not really suited to making technical decisions for our business. We’re missing the value of what technical debt can be, which is a predictable stepping stone to future growth.

We need to be honest about our past technical choices. Debt is something that we plan for, that has a known future cost. Regret is something that we’re remorseful for, but represents a historic lack of planning and unquantified risk. We should be taking risks in the business of software, but they should be sincere and measured actions, otherwise we’re fooling ourselves into thinking that we’re being rational in our business.