12 dark secrets of technical debt

In the beginning, programmers didn’t worry about the past. They opened an empty file and created something out of nothing. Everything was a green field.

Those freewheeling, unencumbered days are long gone for most of us. Much of software development today is revising, extending, enhancing, and evolving what we — or more often, someone else — did before. Enter technical debt.

The term technical debt is a useful way to refer to something left undone. The debt is that we now have to go back and make right, either by fixing or filling in the gaps, what we did last week, last month or even years before.

In the planning phase the term is a good shorthand for work that is often forgotten. Stakeholders are already churning out lists of new features and enhancements, but if someone doesn’t push back, all of the older enhancements will never reach their full potential. They’ll be forever hobbled by missing or broken code that fails at the wrong time.

The tricky part of the phrase is the word “debt,” which denotes an obligation, an indenture, sometimes moral and sometimes legal. Debtors’ prison may be long gone, but in the software world technical debt can be a kind of prison all its own — if it can’t be ignored.

Here are 12 dark secrets about what we owe our software stacks.

Technical debt isn’t inherently bad

The word  “debt” sounds bad but it doesn’t always reflect poor judgment. Technical debt almost always emerges from a bout of new development that expanded the stack by adding a bunch of new features. The developers didn’t get to everything on the list and didn’t make everyone happy, but concentrating on that is focusing on the negative. The glass may be half full, but there was barely anything in it before they began. Technical debt is really the shadow left behind by progress.

Technical debt is really infinite

When enumerated, the list of technical debt may seem overwhelming enough, but the real list stretches straight to the moon and beyond. It’s really a list of things the software doesn’t do and this list is infinite. You may focus on the fact it doesn’t export PDF files correctly or some CSS selector is too general, but it also doesn’t implement all three dozen of the latest AI algorithms or use quantum-safe encryption algorithms. Does it read minds? Does it know which cut of jeans the kids will want to buy next spring? In five years?

The point is that technical debt is impossible to measure or codify. If you work really hard, skip lunch and get halfway to infinity, guess what? Infinity is still just as far away and tomorrow you’ve still got a long way to go.

Technical debt isn’t always owed

Technical debt is often in the eye of the beholder. Chris may insist that we need to expand some data archive or rebuild some API to accept a different query but Chris also spends half of the evening arguing about Area 51 on Reddit. This is not to pass any judgment on whether aliens are really at Area 51. Only to point out that most businesses have been able to do just fine without making a decision about the matter. The same could be true for the API feature set that Chris wants to implement.  Perhaps Chris is spot on. Perhaps Chris is off on an expedition into outer space.

No one actually ever collects

Technical debt is not like a financial debt where the bank will come and take your platform if you don’t pay. Nor will repo men arrive in the middle of the night to run off with your code. Technical debt is purely an internal accounting mechanism that can help us track what needs to be done. It’s like a one of those “To-Do” note pads, but with a fancier buzzword.

Technical debt can sometimes be like financial debt

The tricky thing with technical debt is that some technical debts are financially serious. Maybe an important client will leave if the API doesn’t support JSON. Maybe a new rival is stealing customers by offering to work with NoSQL databases. The challenge is measuring the amount of this financial exposure and then making a sane business decision. If the downside of ignoring the debt is much less than the cost of satisfying it, then it makes sense to ignore it. But if the cost is high, well, it’s time to get to work fixing that problem.

Technical debt can be a political fiction

Many people who want to fix some technical debt are firmly in some political camp and they use the term “debt” because it sounds more persuasive and earnest than to put something on a “technical wish list.” These factions may or may not be important to the future of the company and the software you’re working on. If your business wants to get more contracts in New Jersey, well, it might be good to make sure your software works well with the big spenders in New Jersey. If that’s not a big part of the company’s goals, well, the debt may not need to be paid.

Technical debt sometimes just disappears like a rash

Many people have had good luck ignoring some of their rashes because the body does a good job of healing on its own. Technical debt often fades on its own too. It may seem important to support some essential file format today, but sometimes a new file format comes along, eclipses the old one, and makes it unnecessary to support that old one because everyone has forgotten it. There are millions of scenarios where technical debt just evaporates. Ignoring it is a perfectly good strategy as ignoring skin rashes — as long as you’re sure it isn’t skin cancer.

Technical debt is hard to pin down

Is what someone on the team is calling “technical debt” really a debt? Or is it just a feature that someone wants? Just what do we owe our users?

Technical debt can often be merely cosmetic

Sometimes a feature that slips into the technical debt column turns out to be merely cosmetic. This is always an issue for managers. Some problems require elaborate rewriting of vast parts of the current software stack and some can be eliminated by some clever repackaging of the current code base. The challenge is to see through the moral fog of something that sounds like technical penury and make practical decisions about offering features that cost the least to deliver.

Technical debt is never settled

Screenwriters love debts because they drive the protagonist and have some nice, satisfying resolution. In one move, Nick Cage must steal the 50 cars, After 49, he’s still in debt. When the 50th is delivered, he’s in the clear. The debt is settled. The credits roll.

Technical debt isn’t the same. Oh sure, once you start accepting XML files, you’ll stop getting pointed requests from your boss. You can close out those tickets and see a big jump in the graph of closed tickets. But 9 times out of 10, the good deed will just generate new debt. The requests for XML input will be replaced by tech support for this new feature. New code creates new issues and technical debt is settled with new code.

Technical debt isn’t numerical — and thus hard to measure or track

Whereas monetary debt is measured in numbers, technical debt can’t be measured without waving hands. Sure, the agile gang will try to count the number of “points” it will cost to implement something. Smart managers will be able to guesstimate the developer time in hours. But those are all guesses and anything could happen. It makes you yearn for the gangster movies with the loan shark who knows exactly how many dollars he wants.

Technical debt can be an opportunity

The old joke goes that if you owe the bank $100,000, you’re in trouble but if you owe the bank $100 million, the bank is in trouble. Some of the developers may talk about the debt as if it’s something you owe but it’s more of a chicken game between customer and supplier.

If that someone can take business elsewhere, you’ve got to earn that business. You better fix your code. But if that someone really needs your stack and can’t migrate easily, the technical debt may really be a technical opportunity to upsell someone. How much will your users pay for the new feature?