Technical debt doesn't necessarily need to be just badly implemented code. Or some shortcut that is suboptimal to the long-term goals of the company. It can also be any code related to the non-essential part of the project.
For example, something already exists as an established service, but you decided to implement it yourself. These can be services like payment processors, email and SMS senders, or even backends and databases. And reinventing the wheel is technical debt.
Forms Of Technical Debt
The primary separation is between intentional and unintentional technical debt. Unintentional technical debt is usually a smaller part of the problem any project faces. And even then, it is hard to blame yourself for the things you couldn't know. You did your best, and that's all that matters.
Intentional Technical Debt
This type of code is usually the biggest problem. Intentional technical debt plagues codebases throughout the world. And it is the result of the assumption something can be gained by doing things badly.
The main catalyst for such behavior is a lie that project managers and business owners like to tell themselves: "it's just temporary".
Usually, when they feel the pressure (real or imagined) regarding deadlines, good business practices break down. The future seems so distant and irrelevant, and the present so important. The result is cutting corners and other bad practices, which are explained in this article.
Are Bugs Technical Debt?
It is important to distinguish technical debt vs. bugs. Bugs are not technical debt. You can have no bugs and a lot of technical debt. However, having a massive pile of bugs can be a symptom of technical debt.
The most prominent manifestation of technical debt is development speed. While it usually also produces more bugs, you can be bug-free if you're careful enough. But what you'll notice is that it takes longer and longer to develop additional product features.
So every potential short-term gain in speed you achieved in a 1-2 week time window is quickly lost in a 6-12 month window. And it doesn't stop there - it compounds further and further. All you did was dig yourself a hole in which you'll fall 6 months down the line.
Programming Technical Debt
Technical debt acquired during the early stages of the project is the most dangerous. Since everything else builds on top of it, every mistake you make propagates and amplifies the problem throughout the project.
Every shortcut you take inside the code will cost you much more than you expect. That is why planning everything in detail in the beginning, is essential. Your mind will object because it seems like you're doing nothing when you take your time to devise a plan. But don't be fooled. This is the biggest opportunity for acceleration you'll get for the rest of this project. So use it wisely.
Especially when considering your project's architecture because infrastructure technical debt is the most dangerous form of technical debt.
Languages And Frameworks
Besides bad code, another thing that can be considered technical debt is choosing an inappropriate programming language. Even if your code is perfect, just by choosing C++ to create a website instead of Node, Python, or PHP - you instantly added a ton of technical debt. And that is because you're using a suboptimal solution for a given problem.
The same situation happens when choosing frameworks. Any time you don't select an appropriate tool for your specific situation, you're slowing down your project and automatically adding technical debt to it.
Not Using Existing Services
You create technical debt whenever you implement non-essential functionality instead of using established solutions and services.
For example, there is no need to implement your own email sender when other solutions already exist. The same applies to payment processors and many other functionalities your software project often needs.
The key is to focus only on developing functionality specific to your product. And that's it.
Ignoring Trends And New Technologies
Your project should not use every new experimental technology because that is a sure way to actually increase technical debt. But if you catch recent trends and discover good and tested tools, then definitely use them.
In the end, some of your competitors will use those same tools, giving them an advantage over you. So it is wise to use these tools before they totally become mainstream.
For example, the talk about no-code platforms is increasing. They have already existed for years and are well tested by now, so it's pretty safe to use them. The fact that not everybody is using them already is the exact reason why you should. Because it will give you a market advantage.
8base database is one such no-code platform that gives you incredible options when building your backend. Ignoring its existence is automatically creating technical debt.
Why? Because your competitors are not going to ignore it. This means they will use more powerful tools and outcompete you with little effort.
Specifically, this 8base platform allows you to create database tables through a visual dashboard in just a few clicks. On top of that, the API endpoints are automatically created, and you can connect to the backend immediately.
It is production ready out of the box, and it's up and running right away. Oh, and by the way, it is automatically scalable from one to a million users (or more) with no extra setup required. Not to mention you only pay for what you use.
So, if you ignore this powerful tool's existence, how do you plan to win? How many developers do you need to develop something remotely close to this? How much time will it take to do this through code manually? Not to mention, how much would all of this cost?
It is pretty clear that if your competitors use 8base and you don't - you won't stand a chance. And the same is with every other established tool. And if you're not using those tools, you choose to intentionally add technical debt to your project.
Zero Technical Debt
This is the ultimate goal. Having no technical debt enables your company to achieve maximum long-term speed and the biggest market probability of success. Everything else is just shooting yourself in the foot.
And if you have a competitor with less technical debt, they are more likely to win. Because they can innovate faster, at a lower price, with fewer bugs, and overall better experience for their users.
