The Cost of (Technical Debt in) Doing Business

Ten and a half years ago, I wrote an article on technical debt strategies.  It was one of my most commented-on posts, and even got its own discussion on Reddit.  The point wasn’t to explain what technical debt was, but I did so (briefly) anyway, near the top:

In software development, there is always a tension between two opposing forces: the desire to do it fast, and the desire to do it right.  ...  If you do it right, then, later, when you want to extend it, or modify it, or use it as a jumping off point for branching out in a whole new direction ..., you can do so easily, with a solid foundation as a base.  The downside is that it will take longer.  If you do it fast, you get results faster, which means you can serve a customer’s needs before they change, fill a window of opportunity before it closes, or perhaps even beat your competitors to the market with your offering.  But when you have to modify it later (which you will), it will end up taking even more time to clean things up than if you’d just done it right in the first place.

You can see why we often call this “technical debt.” You’re saving time now, but you’ll have to “pay it back” later, and the amount of extra time it takes is like the interest.  Primarily, we software people invented this analogy because it makes good sense to business people.  ...

And I still say it’s a good definition, despite the snarky commenter who said it was “actually a definition of bad coding practices.” If you want a more complete definition—and some interesting history—you can find that on the Internet, though I’ll maintain that it’s not a better defition ... just more detailed.  Other Internet articles can explain even better than I could how the technical debt concept (more of a metaphor, really) neatly parallels the concept of financial debt, but, again: the analogy I used to follow the quote above is perfectly adequate for grasping the concept.  If you have a business, and you need a piece of equipment that costs $1,000, but you don’t have that much in the bank, you have two choices: you either wait until you do have that much in the bank, or you borrow some money and buy the thing now.  In the first case, you end up debt-free, but you’re paying what in business circles is called “opportunity cost”: if you lose money (e.g. to your competitors) because you couldn’t use that equipment while you were saving up the money, that’s the opportunity cost.  Contrariwise, if you borrow the money to save the opportunity cost, you’re paying interest, which is what we call in business circles actual cost—i.e., cash.

In fact, the concept of “opportunity cost” is a perfect companion to that of technical debt.  In both cases, you’re not talking about “real” money, in the sense of dollars you can count, but you are talking about real financial consequences, even if they can be hard to measure exactly.  And the point of them is the same: to turn something that’s a bit abstract and hard to grasp into financial terms, which businesspeople are really good at understanding.  If I had heard someone tell me that some business people were starting to think that opportunity costs were bullshit made up by other people to get them to do things they didn’t want to do, I would think that was crazy talk.

And, yet ... that’s exactly what I just recently heard said about technical debt.  That business folks weren’t taking it seriously any more because they thought it was just this made up thing to get them to take software maintenance seriously.  Which ... well, of course it is.  Just like opportunity cost is a made up thing to get people to take seriously the idea that waiting has consequences.  That doesn’t make the consequences less real, though; the fact that someone made it up at some point is true of everything in our society.  The idea of “running a business” was made up at some point, as was the title of “CEO,” as was the concept of “management” and the practice of “accounting.” But no one questions that these things are real, because, you know, they are.  And technical debt is real as well.  Trust me, I’ve been in software development for over half my life now: it’s very real.  Doing things fast (most often in order to avoid paying “opportunity costs”) is the choice most often made by the business side, and to be fair there are often really good reasons for choosing that.  But the costs are quite real, and quite often painful down the road.  Pointing out that someone had to invent a phrase for it doesn’t make it go away.

The thing that really frustrates me about this apparently growing attitude is that we (technical people, I mean—the term was invented by the same guy who invented agile programming) invented this stupid term so the business people would take the problem seriously.  Ward Cunningham, bless his soul, came up with the perfect metaphor—technical debt is the interest you pay when you borrow time to pay off your opportunity costs—and now the business people are rejecting it as “made up”?  Perhaps this is the real difference between “opportunity cost” and “technical debt”: the former is what business people use to justify expenses to their accounting departments, while the latter is what the tech departmnent uses to justify expenses to the business people.  So when the business folks are the justifiers, the term makes total sense and we should all use it.  When they’re the justifiees, though ... well, then it’s all bullshit.

To be fair, though—which I am very much not inclined to be on this issue—I should point out several of the articles I’ve cited claim that this is all our fault.  The technical people, says one, overused the term and just applied it to all their problems.  Engineers, it says, say “technical debt” when they really just mean “bad code.” And of course code can be bad for a myriad of reasons: technical debt is a big one, but certainly not the only one.  It goes on to lament:

When businesspeople don’t want to grant a “tech debt week” because they saw with their own eyeballs that the last one improved the team’s capacity zero percent, how can we expect them to grant us another one with alacrity?

Well, I’m not buying that.  If a business person says to accounting, “I’m going to borrow money to buy this thing,” and accounting responds, “don’t do that! it will cost us a million dollars in interest!” then I’m pretty sure there’s going to be some fact-checking going on.  What I’m saying is, the business folks have to bear some of the responsibility for not bothering to take the time to understand exactly what technical debt is being paid off in a “tech debt week” and what the benefits will be.  Also, what are the chances that the team will achieve their goals?  Because sometimes ripping out the kitchen cabinets and replacing them with ones where the doors aren’t falling off takes longer than the contractor’s initial estimate.  This is all very standard stuff that any businessperson worth their salt would consider when buying a physical item or hiring for a particular job.  And, if the business side asks, and the tech side has to explain themselves, then they’ll rapidly become disabused of the notion of throwing all their problem code into the “tech debt” bucket.

Another post offers the tech side this advice:

Instead, say: this is how long it will take to do.

Not “if we rush we could probably do it in...”; no, if you say that, then why are you not rushing now? Do you not care what the business wants? Do you not have ‘skin in the game’?

Say: This is how long it will take, we estimate. If you want it faster, we can cut some features.

Again, this is not how things work in the real world.  When the plumber comes by and says, “I’ll need to replace this pipe, because it has a hole in it.  It’ll take about 4 hours to get it done.  Or, I could do a quick patch job on it and get it done in an hour.” you don’t respond, “Why aren’t you rushing now?” You ask what the consequences will be for that rush job.  Is it going to keep leaking, just not as bad? is it going to stop the leak completely but only for a few days, and then you’ll just have to call the plumber back again?  There’s obviously a reason why they’re offering you the option of doing it right vs doing it fast, and you will certainly want to hear that reason.  But under no circumstances is the fast option “cutting some features”: it’s delivering the same features with substandard quality.  That is the entire point of technical debt.

But my favorite one is this, from the very first article I referenced:

In an impassioned post, a long-time software development consultant, Uncle Bob writes “A mess is not a technical debt. A mess is just a mess. Technical debt decisions are made based on real project constraints. They are risky, but they can be beneficial. The decision to make a mess is never rational. It’s always based on laziness and unprofessionalism and has no chance of paying off in the future. A mess is always a loss.”

This is such complete and utter horseshit that I’ve pre-emptively lost all respect for this “Uncle Bob” character, and I don’t even know who he is.  The fact of the matter is, sometimes you make the decision to do the quick patch job, because you really need that pipe to work for just a few more weeks, and the inevitable resulting mess—which, depending on the size and location of the pipe, might be prodigious indeed—is absolutely not the result of being lazy or unprofessional.  The customer (who is in this analogy the business side) understood and accepted the risk; the contractor (here representing the technical side) was neither lazy nor unprofessional: they did exactly what was asked of them, almost certainly over their strong objections, and definitely cannot be held responsible for the resulting water damage.  I have to believe Uncle Bob never had to pull an all-nighter trying to “just make it work” for the customer demo the next day.  A mess is not “always based on laziness and unprofessionalism”; a mess is, sometimes, just the best you could manage at the time.

So I suppose the business people will continue to crack the whip and the technical folks will continue to beg to be able to clean up their messes, and now they’ve even taken away the phrase we used to help them understand the urgency.  I don’t really blame the business people in my own company: they’re just responding to the zeitgeist.  And I’m still not buying this notion that I should blame the wider tech community—it’s 100% true that some engineers have doubtless misunderstood the proper use of the phrase, and that’s contributed to its being misused and consequently watered down.  But I find the parallel of “opportunity cost” very instructive: its challenges are similar, people often misunderstand its use and try to appropriate it for their own purposes.  But it continues to be useful (and to be used) anyway.  And I think that’s because its use benefits the business community, so they resist any abuse of it and hold onto it fiercely.  The concept of “technical debt,” on the other hand ... that, they have have little use for, so it’s fine if it falls into disuse and neglect.

Of course, one might argue that, by not understanding technical debt (and not devoting resources to pay it down), the end result is that the company has to spend more and more time to achieve the same results.  That’s time that businesses could be spending making customers happier by delivering more quickly, responding to competitive threats more nimbly, or breaking into new markets with innovative new features.  What I’m saying is, rejection of the concept of technical debt, in my opinion, has a real opportunity cost.