If you work in IT, you probably have seen or heard the “technical debt” term. Do you know what it is? Just as the name suggests, it is a type of debt, and nobody likes to have debts, right? Similar to monetary debts, if we do not repay it, it will accumulate interest and make our work harder and harder. It may be complicated systems, lack of tests, non-documented code, tightly coupled components, complicated infrastructure or just lack of module ownership. Sounds familiar? Yes, it is a frequent problem in software development, but not only there.
Technical debt is often created when we have a fresh, great idea and want to expand quickly: there is no time for polishing, we want to cover as many needs as possible and find investors. It is fine, if we will focus on details, we can lose our chance or be overtaken by bolder competition. In effect, we often create something called “big ball of mud”: it will work, but it will hard to maintain, it will be something like mix of different solutions, lack of plans, lack of information. Such a mix based on the knowledge of team members and if they will leave, everything will be complicated for new employees.
Table of Contents
Technical debt can destroy a company
A notable example of technical debt is Symbian, an old mobile operating system created by Nokia. I have used Symbian for a few years on different devices and it was fine, but I did know anything “under the hood”. The truth was a bit scary: the system was super complicated, the building process was awfully long, testing was almost impossible. In effect Nokia hit the wall and it was not able to extend or improve Symbian anymore. Next part of this story was sad: Nokia was acquired by Microsoft; they completely stopped all projects related to Symbian and moved to Windows Phone only. Unfortunately, Microsoft failed to properly advertise and develop Windows Phone and after just a few years, this project was canceled. Nokia was sold again and was almost non-existent for some time. Now it produces phones, but they are only a shadow of their former power.
We can find many similar examples, even companies like Facebook, Google, Amazon or Netflix had and still have a lot of issues related to technical debt: there were a lot of moments when these companies were close to “death” because of that. These companies were not able to deliver new functionalities, compete on the market and attract new customers. Why did they survive and Nokia not? Because the magnitude of the problem was realized in time and faced up to it, instead of sweeping the issue under the rug – it was always hard, but required time, something like a big house cleaning before Christmas. Probably nobody likes that, but can you imagine Christmas in a mess?
Is technical debt always bad?
Based on previous information, you can assume “yes”, but the answer is more complicated. technical debt is not bad, it is not good. It just exists because during our work, we have to deal with a lot of complicated problems and in many cases, do not have enough time to do this correctly. If we must compromise, we will generate new technical debt. In the ideal world, we can always make correct decisions, we always have time to handle items in proper way and do not generate any bottlenecks and issues. Unfortunately, we do not live in an ideal world: deadlines, customer requests, competition. All these factors cause us to take shortcuts, generate new debt, for example by extending old codebase instead of making refactor, by skipping important tests or critical validations on CI/CD pipelines.
But technical debt can be beneficial. If we will remember about its existence and periodically clean up the mess, we can also adopt (yes, like in AGILE), learn, and do not repeat similar mistakes in the future. Probably we will never completely avoid technical debt, but we can learn how to live next to it and keep growing. And it is completely fine. Also, remember, that “technical debt” does not mean only IT projects. We can use the same words to describe even our personal troubles, it works in the same way and… Maybe it is a good analogy to explain how important it is?