Technical debt and legacy code are closely related but not exactly the same. Legacy code is a derogatory term to indicate old code that is no longer well-maintained. Technical debt, on the other hand, is debt accumulated in order to release software. It can be more than just your code. Let’s take a look at the different kinds of technical debt that we can accumulate.
Code Debt
Code debt is the most obvious form of technical debt. It’s what matches best with the term “legacy code”. It’s code that still serves a purpose but developers don’t like for a myriad of reasons. Maybe shortcuts have been taken; maybe the code was well-written but no longer holds up to modern standards.
This is what your developers mostly mean by technical debt. Fixing this shouldn’t be too hard most of the time. Experienced developers that get time and trust from their management should be able to improve this dire situation. They’ll add automated tests and refactor the code to make it more stable, maintainable and performant.
Architectural Debt
Taking a step back to see the bigger picture, you might also have architectural debt. You code might be pristine, but maybe you’re doing SOAP instead of REST calls. Or you might still be running on costly on-prem servers and need to move to the cloud in order to scale.
Whatever it may be, architectural debt is often built up over time and due to changing conditions. Our IT space evolves so fast that good solutions at one time have better options 5 years later. And most software has a lifespan that is longer than that.
So inevitably, you’ll end up with architectural debt. Solving architectural debt often requires a little more effort. You’ll need to analyze the possible alternatives to your current solution. They might not have all the features you use and need now, so you’ll have to find ways around that. Once you know the way forward, implementing and releasing this is often non-trivial.
You’ll need an experienced team, ample time and a good and clear plan to fix architectural debt. But the solution is out there. It involves moving over to modern platforms and adopting modern standards.
Tool Debt
There are a great many tools out there that significantly improve the life of developers and managers. Think about tools to monitor your application, to alert you when things go wrong, to keep your logs centralized, etc. But also project management tools or source control systems are tools that help out in the daily life of a software team.
These tools can also be a form of technical to you. This technical debt could have been a deliberate choice at the time (e.g. we need a free monitoring system because budgets are tight). Or it could have formed because you outgrew the old solution (e.g. an Excel sheet is no longer sufficient to manage the backlog).
Whatever it may be, these tools can start to become more of a burden than a help. At that point, you need to look at two things:
- do we still need this kind of tool (i.e. do we still have this problem or can we do without it)?
- if so, what would be a better alternative
Library Debt
Library debt is technical debt that is due to outdated, insecure or no longer maintained 3d party libraries. Any piece of modern software contains libraries: bundled pieces of code that others have created so your team doesn’t have to implement the supplied functionality.
While it’s definitely a good decision not to write all the code yourself, it can happen that a chosen library becomes a piece of technical debt. Especially when the original authors no longer maintain the library. This increases the chances that bugs are no longer fixed and that security issues may arise.
The solution here depends on whether there even is an alternative. Sometimes, a newer library exists. But sometimes, you may have to implement the required features yourself. Unfortunately, this now means that you have to maintain this code, adding extra work to your team.
If possible, it may be a good idea to contact the original authors and see what can be done. Maybe it’s cheaper to pay them to do the fixes. Or maybe you can take over the library and profit from the advantages of open source: visibility for your company and input from the community (bug reports, help in fixing bugs, feature requests).
External Services Debt
A final type of technical debt we can encounter is external services debt. Many applications integrate with other applications. This ranges from technical concerns like databases to end-user functionalities like social networks.
Moving away from these can be a bit tricky, as the code is often strongly tied to the specific service. Here, careful planning and a good analysis is required. You probably want to set up a test environment with the old service first, so you can practice the migration.
Not All Hope Is Lost
If you get a feeling of dread after reading this because you’re now thinking about all the places where you’re building up technical debt, don’t despair. Technical debt is everywhere, even in great teams that take time to write quality code. The difference is that high-performing teams know where the debt is, know how they want to solve it, and know their priorities. We can’t solve it all at once, but we can continue to work away the debt, regardless of the form in which it manifests itself.