Published: September 15, 2021
9 min read
Last updated: May 2, 2022
In this article, you'll learn:
📊 Approaches to Handling Tech Debt
🤖 How to Manage Technical Debt: Our Expertise
✅ Our Approach to Handling Technical Debt: General Tips
Having technical debt is 100% okay. For example, it’s a natural “legacy” of many companies that rush to bring a satisfactory solution to the market. This allows them to start making revenue and collecting user feedback early, so they have enough resources to address these issues in the future. Done is better than perfect, right?
In fact, based on McKinsey’s research, 70% of companies spend 6-20% of their annual budget on “paying off” technical debt. Moreover, ScienceDirect reports that even large well-organized companies allocate 25% of the whole development time (on average) for managing tech debt. But the thing is that each company defines technical debt differently.
If you’d like to manage technical debt at minimum cost, check out our article for hands-on managing technical debt strategy (image by Trace Byrd)
As we’ve said, the widespread definition of it is the result of preferring delivery speed over perfect code. Yet, apart from time pressure there are many other causes of technical debt accumulation — it can be delays in refactoring, new technologies occurrence, lack of technical knowledge or code documentation, budgetary restrictions, etc.
Even though there are some techniques to prevent technical debt from accumulating, sometimes it can get out of hand. That’s when it can no longer be ignored and requires more proactive approaches to be dealt with.
In this article, we’ll talk about ways to handle the debt, share our experience of covering it for our clients, and give you a step-by-step guide of what to pay attention to when preparing to tackle it.
There are 3 main ways to handle technical debt:
To reduce technical debt, you can enable automated testing for bugs and performance quality tests (image by Ai Power™)
Rewriting the code might be reasonable when the technical debt is so massive that it’s much cheaper, faster, and more efficient to simply rebuild the product. Apart from a huge debt, reasons can be the following:
Coding solutions anew as a concept of handling existing technical debt with making technology and feature improvements suits well for covering drastically new business needs (image by Ricardo Klement)
Another approach to repay technical debt is to modify the existing codebase. You should opt for this option if there are no significant changes, it’s probably not worth it. Let’s take a look at some particular reasons:
Software development will inevitably require you to cover long-term and/or short-term technical debt (to add new features or address a small bug backlog respectively) (image by Blaze)
One more way to handle technical debt is a hybrid model where a part of code is worth rewriting while some of it will be decent with just a little improvement.
For example, it may be the case when you need to fully rebuild your BackEnd while just slightly modifying the FrontEnd. Also, this approach is often used when working on products with microservices architecture.
Such a model is quite easy to define — if you can apply use cases from the first way to one part and those of the second one to another, you should opt for this model.
As a development company, we have a lot to do with handling technical debt for our clients and have assembled quite a lot of experience that we’ll gladly share with you. By getting acquainted with our cases, you might get some ideas for your project and prevent certain mistakes in the future.
We’ll give you a couple of examples for each covering approach.
A team that was working on this project before set up CI/CD (Continuous Integration/Continuous Delivery) using already deprecated versions of the libraries. The platform that this team used for the setup announced that these library versions would be supported for a limited time. It was the signal for the development team to update it during this time to prevent troubles.
However, previous developers failed to seize the moment and didn’t perform the update. After some time, we took over the project and started to deploy the backend code using the existing CI/CD configuration. Everything was fine for some time, yet, the code suddenly wasn’t able to pass certain deployment stages. As a result, we couldn’t release new product updates.
Our team was trying to fix the problem locally but then we realized that the platform simply stopped supporting these library versions. The only reasonable solution was to fully rewrite the CI/CD process since it wasn’t possible to change the code on the failing steps only.
This case is a great example of how technical debt can occur due to a lack of attentiveness to changelogs that each platform provides. Such troubles can be easily prevented if your development team keeps an eye on things like this and doesn’t dismiss them.
If you decide to rewrite the project some time after completing software development, make sure to look at how other developers and teams handled it to get some ideas for your own development and see how it affected them in the long run (image by Damian Orellana)
There was another case where the backend was fully written in Scala, which is quite a rare language to use as of now. As a database, they used MongoDB. It was quite an (unnecessary) challenge to support the product in the way it was. Thus, to prevent future problems and needless expenses, we’ve decided to write our own server with NodeJS.
At first, we connected it to the old database and were gradually transferring parts of the old server to the new improved one. Once our server was able to process most of the requests, we started rewriting the database as well. In the beginning, we were sending the data to both servers but eventually shut down the old one.
Such a tech debt handling type is something rather inevitable. This is why there are multiple cases that can be used as an example. We’ve selected the most representative and diverse one.
We’ve got to work with improving the digital product’s code:
Handling technical debt with help of system refactoring implies developers running continuous testing of the software and technology to spot system bugs and/or other issues (image by DragonSpears)
We’ve also had to take care of improving the backend code in multiple aspects. For instance, architecture changes like making the entity scalable, preserving backward compatibility and data integrity when updating the system while satisfying the requested business logic.
Moreover, there were cases where we performed system localization (for products that didn’t initially imply such a process) and integrated third-party services.
One of the most widespread cases of such an approach that we had to handle is a well-functioning frontend with almost 0 critical issues (design is suitable and the whole workflow is stable) with a problematic backend that has data processing troubles.
To handle technical debt that arises while developers build a software (or any type of digital solutions), it’s important to test how the debt impacts all the other parts of the product (image by Toptal Designers)
In such cases, fixing the “bad” backend would require rewriting a lot of other backend-related aspects, which is why coding it anew would be a lot cheaper and faster. At the same time, the frontend gradually gets updated as you add new functionality.
If you need to handle technical debt for your product, the first thing you need to do is to collect the maximum amount of information possible. As obvious as it sounds, it’s not always easy to ask the right questions.
To provide you with a template of what you should pay attention to, here’s what we start with when asking our clients regarding their technical debt or handling it for ourselves:
To cover technical debt at minimum cost, you should allocate time and resources for completing tasks regarding it in advance (image by Ju Jung)
Most likely, you won’t have answers to half of these questions straight away but it’s totally fine. Take time to do your own examination and note all the issues along with possible solutions that come to mind.
Additionally, it can happen that you can start working on your technical debt with the permission of C-level employees only, but they might not have the sufficient level of technical knowledge to understand the importance of covering it. In such cases, we’d recommend addressing the issue from the point of value. That is, what the company will get after handling technical debt:
All in all, technical debt isn’t just a burden that you need to carry — it’s a wonderful opportunity to implement collected feedback from your customer to provide a better user experience and thus, be more attractive to potential customers.
If you have any questions on covering the technical debt left or need the help of an experienced development company with it, feel free to reach out to us!
Was it helpful?
How to Make your React Native Application Accessible to ALL, not just to MANY
Which Payment Providers should I use for my SaaS Product?
How to Monetize Your SaaS Product: Pricing Models and Strategies for Success
Our clients say
When I was working with Stormotion, I forgot they were an external agency. They put such effort into my product it might as well have been their own. I’ve never worked with such a client-focused company before.
Alexander Wolff, CPO