Economics of Tech Debt

Can I say some technical debt is good to have?

To make my point I’ll draw an analogy from financial debt, ordering from worst to best.

Car loans

This is the worst kind of debt. You pay steep interest, but your asset depreciates right away.

What’s the equivalent in tech debt? It’s unmaintainable code.

• Code is full of method names like doIt1(…), doIt2(…), doItInner(…).
• An algorithm you hacked together into a bowl of spaghetti with levels of nested loops and early exits (breaks, returns, …), variable names like i,j,k with no explanation of what it is doing.
• Behemoth classes with no coherence, and shared state across its many jobs. (Shivers)
• 10 string arguments in your method signature that you were too lazy to form into a parameter object with stronger types.

When the time comes, you will have to redo it, and then some.  There’s no fixing that stuff. 

You’ll try to call it a refactor, but we all know it’s a rewrite. 

The longer you avoid rewrite, the more bugs will come your way. Until your company is bought by a competitor who was smarter with their debt management. You’ll lose your job – but at least now you’ll get some sleep.

Don’t do this kind of tech debt. Or if you did it, pay this debt FIRST. This is the tech debt that is most expensive to keep.

Credit cards

These are the ones that you pay a decent interest on, but you do it if it lets you invest in what really matters. 

In tech debt this is like using off-the-shelf (or SaaS) instead of writing it in-house.

• Making a game and need a payment system? Just use something and pay for it. Focus on the game.
• Building a hospital information system, and need a solver for scheduling? Don’t write a solver. Your time is better spent on all other stuff. 

But don’t be like IBM. They had Microsoft write DOS and BASIC for them, while IBM had the dominance in the computer market. That dominance didn’t last long.

So don’t take on this kind of tech debt if it’s relevant to long-term goals and skill development, or if it will be a part of your competitive lead.

Mortgages

Houses are very expensive, yet a mortgage lets you have one by paying very little interest.

Eventually you will pay the whole amount, but for now, just a little interest.

In tech debt, one example is mocking, or prototyping.

There’s a big development chunk that you know you’ll have to implement at some point. It’s a lot of work to have it work properly, and it’s blocking your pipeline, but it’s easy to mock it for that MVP.

• You need online GPT integration that needs a data pipeline with RAG (stuff that bridges GPT to your data), an Observability infrastructure (stuff that you use to track production performance). But for now it’d be okay with a local model and a few lines of python.
• You feel like you should optimize that algorithm but nobody will notice because the amount of data is nowhere near where that optimization would matter. Skip it. Do it simple and dumb.

Make interface the same so eventually it’ll be easy to switch over to the real thing.

Mocks are cheap, and when the time comes to do it, you’ll just have to pay the original capital anyway (as well as the cost for the mock).

Pay a few days now to postpone months of work and unblock your pipeline.

Parent loans

This is the debt that you pay no interest on. It’s almost better to have it than not 🙂

In tech debt this is that partial implementation. 

• Let’s say you need your service to talk JSON, and you don’t have access to a standard JSON library. Of course you need a serializer, a de-serializer, and while you’re at it why not, a prettifier, too. That’s a lot of nasty work.
  
  (If you think it’s not, just go write one and test it against some JSON files in the wild).
  
  But maybe, just maybe, for just today, you only need the serializer that makes the damn JSON. Not the de-serializer or the prettifier, at least not today. So leave it out!

If you want to avoid design debt, put the design in place but throw a NotImplementedException and call it a day. If someone eventually needs it, you’ll know right away it’s missing. (Lean people would call this avoiding waste)

Worst case, when the time comes, you’ll just have to do the thing itself, with no interest. Or maybe, just maybe, Java will finally add a standard JSON library, and you won’t have to stand behind your debt. Loan will turn to a gift.

So

Tech debt isn’t always evil.

Borrow wisely and invest it – you’ll grow.

Borrow foolishly, and you will pay compound interest in bugs and rewrites. 

Huge thanks to Christopher Okhravi (see his awesome youtube channel) for reading incomplete versions of this post.