Technical Debt

home

 

The 2 neat things about the popular phrase "Technical Debt" are its multi-dimensional awfulness, and its meaning creep. It was originally used as a dumbed-down explanation to a boss: we're not adding those new features because -- hmmm. Saying we need to redo our bad first choice of data structures would only confuse him. But bosses know about money. Got it: "Sir, we're paying back technical debt".

You can tell it's a snow-job phrase since no real technical term includes the word "technical". And real ComSci money metaphors are much weirder. The Bankers' Algorithm describes something that no real banker would recognize. We'd hardly use the word Debt to mean debt. Next in the evolution it turned into a serious one-coder-to-another term, and gradually expanded, as all terms do, into a generic catch-all -- just any sort of fixing-up. Not a long trip, but more interesting than other phrases it likes to be in sentences with.

From an advocate's point-of-view, Technical Debt is why you refactor. It serves the important purpose of naming the thing refactoring fixes. We can now attempt to measure Technical Debt without needing to call it "refactoring needingness". The end result is it's a shibboleth. Technical Debt doesn't give any information except that the speaker is really into refactoring. I mean, "we badly need to refactor because we have a lot of technical debt" is nothing but a circular tautology.

Before going on to mock debt as an analogy, I'd like to try, no jokes, to find a replacement word for technical. For example, structural. Structural Debt would cover the original meaning -- redoing data structures, or design patterns. Bad style gets tossed into the Tech Debt category, so why not have Style Debt? As new features are added with hacks, not supported well by any structure, why not call that Structural Rot? "Rot" is an actual computer term, used for this very thing.

Now let's make fun of the Debt analogy. When we left, our manager was nodding his head agreeing how good it is to quickly pay off debt. Except it isn't. When a company gets a sudden tax break and buys back shares, the market makes fun of them. They had nothing better to spend the money on, so paid back debt. Interest is only a few percent, and any decent CEO can invest in something with a higher return than that. That's the basic theory of companies.

At the other end of the telescope, everyone with a store in Brooklyn knows: "collect what you're owed quickly, pay debts as slowly as possible". And people go to the bank for car loans, home loans. They're very happy when the bank allows them to go into debt. Only a certain type of coder would be so stupid to assume the 2 minutes they've spent thinking about debt has made them an expert.

The debt analogy also misunderstands how managers work. Tell any manager, in any area "we can quickly get useful features out, hiding maintenance costs." Then tell them "or we can spend time on non-productive work that will pay off after a few years". It will not be a difficult choice. They will hear "we can get you promoted, pushing back problems to your successor". Less cynical, they know more about the future direction of the product than you do. Maybe it's going to the Cloud. Maybe it's being retired soon, and we just need to puff up the features to help with a merger.

The worse thing about a debt analogy is that financial debt is in money, which is fungible. Any debt can be paid using cash from anywhere. We've been fighting very hard, for decades, to explain to managers that coders aren't fungible -- people and man-hours aren't interchangeable. There's a book about it. It's the single most important thing we'd like managers to know. We're trying to avoid suggesting that you can spend programmer time like spending money.

Coding is tricky to measure, estimate, or even to agree on what a good program is. We hate that, which means we love the idea of comparing it to anything that uses precise numbers, like debt. Financial debt doesn't even have room for opinions -- if you haven't agreed on the exact numbers, it's not debt yet. Which means comparing a sloppy program to debt is a huge lie. More dishonest, debt has a single zero. If a program has technical debt, it's in relation to no debt -- the single correct version of our program, which, as always, is a nonsense idea.

The way it really works isn't complicated. You've got a bunch of features to add, and a guess at more. You have meetings. You get a rough idea of the expected lifetime. If you think everyone underestimates something by 50%, you take that into consideration. It's a guess, but based on as much information as you can gather. Then rough out a schedule. Having several releases is fine. Needing a rushed release is fine. Then some combination of structural changes and sloppy hacks will do what you need. It will depend on the people working on it, and is another guess.

In short, programs are written based on real needs. If you don't know what those are, for your particular project, find out as best you can. Don't retreat to a context-free world with Platonic rules for a correct design, which includes trying to measure technical debt, or even thinking that it's a thing.

My other beef with this phrase, used as it is now, is that we don't need it. Plenty of computer things work in funny ways and need a clever analogy, but this isn't one of them. If any system has a lot of kludges, it's going to need cleaning up. The explanation where you're paying interest when you work with a messy system -- unneeded. Everyone knows working with a hacky system is a pain. Explaining how "tech debt" is this complex situation where you've "cut lots of corners" is just going to annoy the listener.

 

 

Comments. or email adminATtaxesforcatses.com