Economics of Technical Debt

In software engineering we love talking about technical debt. The problem is though, it is often used as a scapegoat for frustration and bad decisions. Talk to 3 technical leads and 2.5 of them will tell you that you should not have any technical debt what so ever, or have as little of it as possible. Which is understandable considering how difficult it is to dig oneself out of bad engineering decisions. Then ask the same people “why is that?” and you will not likely to hear anything overly coherent.

The problem is, I think, in lack of systemic understanding of the phenomena, and a ubiquitous mistaking of technical debt for, basically, low code quality. And so, I would like to have a stab at trying to explain the idea from the point of view of economics.

Economic systems history 101

For the 99.999% of human history, we lived in essentially hunter-gatherer economical systems. One could describe this as “when you get low on a resource, just go into the wild and get some more”. Humans basically treated the surroundings as an unlimited resource, and we kept doing this in one shape or another all the way through the age of empires and epic conquests.

With populations reaching each other borders, and resources becoming scarce—think middle ages Europe, or pre warring states China—, humans turned to something we could call feudal economic systems. Which were turned inwards to exploit its own people and natural resources through taxation and policies; to squeeze out more money to build stuff. The problem was that those feudal systems are isolated, and so whenever they inevitably run out of the last drops of resources, they would have to cross borders and invade a neighboring country or two.

To solve this problem humans invented a new growth system based on capital investment and debt. Which in turn gave birth to free enterprise and relationships based on economics rather than brute force. And this is where most of us find ourselves in those days. Here how it works:

A thought experiment

Let’s say there is a small town in the mountains, which is pretty isolated from everything else. Let us say there is a construction developer in this town who had recently scored $1M from a construction contract. He took the money and placed them in the town’s only bank.

In addition, let’s also pretend for a second that there is no other money in this town at this point. It’s just the developer’s fee sitting in the bank. Now, here is a question:

what’s the size of the town’s economy at this point in time?

The correct answer is easy, 1 million dollars. So far so good?

Now let’s pretend there is a nice lady living in this town. She bakes pretty dope cookies, and she wants to open up a cookie store. And so she goes to the developer and asks him to build her a store. The developer does his calculations and says it is going to cost $1M to build.

The nice lady doesn’t have the money, so she walks into the bank and asks them to loan her 1 million dollars to build the store. The bank obviously “has” the money in their assets, as the developer has just placed the money in there. And so they loan the amount to the nice lady, who in turn uses those money to “pay” the developer for the cookie store construction.

At this point, something magical happens. Because the developer now “has” 2 million dollars in their bank account. 1 million that they put in the bank themselves and 1 million from the nice lady’s building contract. And hence the town’s economy had doubled in size. More importantly, there are also two working businesses in town now as well.

Then the nice lady makes $1M by selling cookies to tourists who go through the town. She re-pays her debt, and borrows another $1M from the bank to pay the developer to build a cookie factory in town, so she could start exporting those cookies and sell them across the country. Now the economy is worth 3 million dollars: 2 in hard cash and 1 in debt.

Then a local family of immigrants watches the hustle and bustle in the town and decides to open up a laundry shop. And so they go to the bank and borrow $2M, which they “pay” to the developer to build a laundry shop for them.

Now we have $2M in cash in the bank, and the total town economy worth of $5M.

Back to technology

The thought experiment above is obviously very shallow and missing on a lot of important details. But it demonstrates the point that through the instrument of investment and debt, an economic system can bypass the physical resources limit to achieve growth. And that is why modern financial institutions run circles around the old feudal economic systems.

The interesting thing is that engineering projects behave in a very similar way. Just instead of coins and cookies, one deals with engineering effort and products. Engineering organisations even exhibit the same traits as economic systems. For example, the large enterprise organisations, such as Google or IBM, have essentially unlimited resources which they can expand on random projects and acquisitions. Then there is the mid-size corporate market that behaves much like a feudal system—think your local bank or insurance company IT department. And then there are the startups and small businesses which take on technical debt like crazy to get anywhere.

In this aspect, one can look at technical debt as a resource management instrument, much like financial investments. As such, there are good investments and bad ones, and it is a tech lead’s responsibility to understand investment risks and opportunities.

The problem arises when one flatly denies technical debt. Trust me, I’m a technical person myself and it is sometimes challenging to think of technical debt this way because it feels like it reflects badly on my skills as a software engineer.

The reality is more complex than this though. By focusing on exterminating technical debt, one commits a sin similar to exterminating Jewish people because it seems like they’re the root of all problems. Okay, maybe not like that, maybe you’re more like a grandpa who refuses to get a credit card because they think they can pay for everything out of their own savings.

The point I’m trying to convey is that by denying the existence of technical debt, you firstly deny your organisation a very powerful growth instrument, which in turn limits your organisation’s performance to the feudal economic system. And secondly, you expand a lot of energy to look good. I’ve been doing this for 20 years, and I’m yet to see an organisation that doesn’t have technical debt. It’s all the shades of grey one way or another.

The way out

The first step to solving a problem is to acknowledge the problem. Let’s face it, technical debt is not a common cold. It is not something you catch now and then, and get rid off at first opportunity by taking a pill or two. Technical debt always present. It is always in your system, and you constantly get more of it. Shovelling it around and repackaging is not a good long-term strategy. Sooner or later it will catch up with you.

The second step to solving a problem is to understand the problem, to classify it. I find it useful to use real-life financial terminology to label systemic changes. For example, there is a “student loan”, technical debt that you will inevitably acquire by onboarding new people, or adopting new technology. Then there is a “car loan”, it refers to a type of technical debt you collect when you need to get somewhere fast. And then there is the everyone’s favourite the “home loan”, it’s a type of technical debt you take when you need to have a foundation for something new to grow. Labelling a problem will help you to understand whether it makes sense to get in debt in the first place. It also gives you a scale of how difficult it will be to repay.

The third step to solving a problem is to come up with a plan. We call things “plans” not “sure things”, because of the risks involved. And so one needs to understand the risks profile to get a good sense of the problem. There are many types of risks: asymmetric risks, terminal risks, etc. Never take risks that can cause a terminal failure. Don’t take risks where risks heavily outweigh the benefits either. You can also mitigate risks by compartmentalising your systems. Agile, micro-services and intermittent protocols, such as GraphQL are your best friends here.

And above all, always have a plan how you’re going to repay your debt back. Don’t borrow more than you can pay back, no matter how much pressure you get from the business side. Re-financing technical debt is a terrible place to be.

Now that you’ve identified the problem, the opportunity and developed a plan, you can take it to the bank and start building with confidence rather than fear.

Conclusions

As a technical person, I found it challenging to stop looking at technical debt as the boogeyman. Something that is the root of all evils, something to get rid of and not touch ever again. I suppose one needs a bit of courage to embrace the fact that this is not how real life systems work. Technical debt constantly flows in and out of the system, and one needs a set of strategies to help to mitigate the adverse effects it has on technology and people.

But, what is more important, I think, is that one needs to understand that technical debt is an instrument of growth. One has to borrow technical debt to overcome resource limitations and build more complex products faster than otherwise would be possible.

As such, we, collectively need to stop villainising technical debt and learn to use it to our advantage, rather than distantiate ourselves from it out of the sense of dislike and fear. After all to make mistakes is human. It will always happen, so in the end what you do with those mistakes that actually counts.