Causes Of Technical Debt

Almost all technical debt was caused by a decision maker who, at some point, prioritized temporary high development speed in exchange for a huge long-term problem. And the reason is psychological - not technical nor business-wise.

Since human psychology naturally prioritizes short-term objectives, it is no wonder that technical debt is plaguing the software industry.

On top of that, technical debt is not very visible. For example, if you were producing cars with a massive crack in the windshield, those cars would not be hitting the road. And they would most certainly not be in a showroom available for sale. But if those same cars had even more significant issues with the code, no one would notice (at first).

Consequences Of Technical Debt

Suppose a human mind is confronted with a short-term visible impact (1 or 2 extra users now) vs. a long-term invisible danger (failing business in 2 years because of the code you can't even see). Then this mind will choose an immediate benefit in most cases.

It is very hard to choose a long-term over a short-term option, even when the value and danger are perfectly clear. For example, many people who smoke don't really want to do it on an intellectual level. But when you are in a situation of having a coffee, relaxing or having a fun conversation with your friends - it's hard not to smoke.

There is an immediate benefit and pleasure derived from smoking. While the prospect of maybe getting sick in 40 years doesn't look so threatening. Besides, some treatments can already help you today, and in 40 years, the technology will be even better. So you just decide to live in the moment.

Unfortunately, technical debt is much more dangerous than smoking.

Cost Of Technical Debt

The cost of technical debt is that the company can fail because of it. Owners and investors lose their money. Employees lose their jobs. And all because of some decisions and shortcuts that seem so insignificant in retrospect.

Is Technical Debt Good Or Bad?

Obviously, technical debt is bad for the company's and product's future in practically all cases. And the only reason it is considered an option is that it appears to solve some short-term problems.

Effects Of Technical Debt

The main effect of technical debt that everyone seems to miss is that it grows as time passes. And it grows at a much higher rate than expected by the people who initially decided to introduce it.

But there are many more examples of technical debt which can show you how it affects different projects and businesses.

Technical Debt And Firm Performance

Let's imagine business owners and managers had a magical crystal ball. If they could see how their company performs in an alternate reality without the technical debt, they would never consider introducing it.

Unfortunately, they can't see it, so they assume that their decisions and actions made the company grow faster. But in reality, things just got slower. Because the technical debt has high compounding interest. At first, you don't feel a significant effect until suddenly you're overwhelmed by it.

The most likely scenario in which the technical debt is created happens because of the deadlines. Even though in the grand scheme of things, no one will remember a year from now, you missed a deadline. No one will notice that your feature was delayed a day or two (or even a week or two).

However, they will remember the constant bugs you will have due to piled-up technical debt. They will recognize that the new features they asked for are very slow to develop. They will notice your app being slower than it should be. Or that it uses up too much memory or battery when it shouldn't.

And this is the great power of technical debt - it grows unstoppably.

In fact, it grows so much that a year from now, the initial problem you tried to cover up pales compared to the technical debt monster you created. So it is never a good idea to intentionally create technical debt.

Addressing Technical Debt

One interesting thing about technical debt is that it's never a good time to address it. No matter your company's stage, it is never a good time. And that is why technical debt is never "temporary".

The only reason it is introduced is because of a false belief it's just a temporary thing. But in reality, it rarely ever works that way.

Unfortunately, you don't have any choice. You have to pay the price. And if you don't pay the price now, you'll have to pay an even higher price tomorrow. So the best way to go about it is to invest at least 50% of your time into clearing it out.

And the main takeaway for your next new project is to never introduce technical debt on purpose for any reason whatsoever.

The only exception to this rule is if you have a nasty production bug and need to fix it immediately, then do it. But the very next thing you do after that is to clean up that code without delay before switching to working on something else.

INFRASTRUCTURE

Technical debt isn't just related to code. There is also infrastructure technical debt which is even more severe.

Infrastructure includes the programming language you use, tools and services you depend on, and the most essential part of every software project: the database.

Let's say you don't create any technical debt in the traditional sense when creating a database. You may still have the effects of technical debt compared to your competition.

Suppose you decide and create the entire backend from scratch. You code all the tables, schemas, and endpoints by hand.

Your competitors use specialized database services like the 8base platform that allows them to achieve the same things as you, but they do it:

• faster
• less expensive
• more scalable
• less buggy
• easier to maintain

Compared to your competitors, do you not experience the same effect as high technical debt around your backend and your database? Isn't your solution dragging you down while your competitors have all the extra time and capital to focus on key product features? And aren't they outcompeting you on those features because of these advantages?

This is something to consider when choosing your database solution and any other part of your architecture.