Technical debt is a risk that arises in long-term projects. With each new element added to the system, each new functionality, there is a growing risk that outdated technologies or outdated libraries will start to affect the stability and performance of the entire project. Questions arise: how can we effectively manage this technical debt so that it does not inhibit further development? How do we ensure that our systems remain flexible and adaptable, despite the passage of time?

In the complex mediatech environment, where competition is fierce and time to implement new features is critical, ignoring these issues can lead to serious consequences. We have therefore decided to develop a strategy to minimise the impact of technical debt on systems performance.

I am introducing new ones, forgetting the solutions already implemented.... ​

When working on a long-term project that is systematically evolving, the problem of technical debt seems inevitable. We are gradually adding new features to keep up to date with market demands and needs. However, I am aware that some of the foundations of our system become obsolete. This is when the first problems start.

With each update, we are faced with an increasing challenge. Integrating new tools becomes more difficult, and making even small changes requires much more work than at the beginning. New functionality is like another weight we put on an already tight rope.

As a result, instead of innovating quickly, I spend more time solving problems that arise from technical debt.

Challenge: technical debt and project development ​

At first glance, it may seem that outdated libraries or outdated frameworks are just minor inconveniences. However, over time, I notice how these seemingly minor problems accumulate, affecting the stability and performance of the entire system. Any new functionality that could once be implemented quickly and efficiently now becomes a risky process.

Technical debt introduces additional complexity, requiring more and more time to test, monitor and correct errors. I'm starting to see that documentation gaps and difficulties in maintaining technological consistency are becoming more challenging.

In long-term projects, where every architectural decision can have long-term consequences, ignoring technical debt can lead to delays in the delivery of new features, increased operational costs and even the risk of losing competitiveness.

The solution: minimising the impact of technical debt through upgrades ​

Technical debt builds up over time, especially in projects that take years to develop by adding more features. At Neoncube, we have adopted an approach that involves iteratively maintaining the most recent versions of frameworks as possible and periodically reviewing code to identify and rewrite problematic solutions.

As part of our long-term strategy, we embark on a technology review and major update of all libraries every two years. This ensures that technical debt is kept under control and that the system remains flexible and scalable, ready for future challenges.

Iterative approach to minimising technical debt ​

Minimising technical debt in long-term projects requires a considered and systematic approach. We have therefore developed a process that allows us to manage technical debt on an ongoing basis and keep the system in optimum condition.

1. Planning for systematic updates is key to minimising technical debt. Every two years, we set aside time to review the available versions of the tools and identify areas that need upgrading.
2. Identification of problematic solutions involves analysing the source code to look for areas that may be causing errors or hindering further development of the system. The diagnosed elements are designated for rewriting or refactoring as part of the update process. The aim of this step is to prioritise and develop a work schedule that takes into account all necessary updates.
3. Iterative deployment of updates allows the risk of potential problems to be minimised. To begin with, updates are deployed on a small proportion of user traffic - typically around 5%. We monitor the effects using automated testing and integration tools to ensure that the system is running stably. If no problems are detected, we gradually increase the share of the new version until full deployment.
4. A key element of the process is to continuously monitor the impact of the changes made. We compare the performance of the new system version with the previous version. If any irregularities are detected, we withdraw the implemented changes and return to the stable version.
5. We document all changes and lessons learned that can help with future updates. Regular reviews allow us to improve the process and be even better prepared for future updates.

Automation and tools being implemented to streamline the process of minimising technical debt ​

The automation implemented helps us to minimise the risk of potential regressions and streamline the implementation of new versions. Particular attention should be paid to:

• Automated tests, which allow us to verify on an ongoing basis that new updates do not adversely affect existing functionality. They enable us to detect potential problems quickly and efficiently, which minimises the risk of regression.
• Integration tests make it possible to verify that all system components work together correctly after changes have been made. Thanks to them, we identify errors that may occur at the interface between different parts of the system before they reach the production environment.
• A/B testing during the implementation process enables us to direct some user traffic to the new version of the system, while the rest uses the old version. In this way, we compare the results and assess whether the new version is working correctly and delivering the expected benefits. If there are problems, we can quickly roll back the changes, minimising the impact on users.
• Real-time monitoring allows rapid response to any anomalies or problems detected after new versions have been deployed. Monitoring covers both application performance and user errors, providing a complete picture of system performance.

Effects, or why you should... ​

• The process implemented has helped us to minimise the impact of technical debt in a long-term project.
• Regular updating of libraries and frameworks, combined with rewriting of problematic solutions, keeps the code in optimal condition.
• Iterative implementation of changes, support for automated testing and real-time monitoring reduces the risk of regression.
• The process implemented makes the introduction of new functions smooth and safe.
• By updating the system regularly, we avoid costly downtime and integration problems that could result from outdated solutions.
• The time spent minimising the impact of technical debt enables a reduction in the operational costs associated with fixing failures when implementing new solutions and project development.