Turning Tech Debt into Opportunities

“Tech debt” and “legacy code” are terms that usually incite negative emotions. For engineers, it feels like extra work. For those in business roles, it might seem like a waste of resources. But, there’s a positive side to this. Let’s try to look at tech debt from a different perspective, one that can help us grow and innovate.

What’s tech debt?

Imagine you quickly borrow money, at a high interest rate, to solve a problem, knowing you’ll need to pay it back later. Tech debt works in a similar way in the coding world. Sometimes, under pressure, or due to unexpected changes, we pick quick solutions over ideal ones. By making this trade off we will incur future re-work to address the short term gain.

Tech debt can happen for many reasons. There could be tight deadlines, changing goals, or sometimes just not having enough information from the start. One common area where teams knowingly accept tech debt is in automated testing. Ignoring this debt isn’t wise. If left unattended, it can make our systems prone to errors, difficult to debug, harder to upgrade, and overall more challenging to maintain. And worse, often knowledge on how to maintain tech debt becomes ‘tribal’.

Tech debt helps improve things for users

Most teams have a list of tech debt tasks. These might include updating old code, migrating data to a new system, or even redesigning a feature. This isn’t just about fixing things, it’s often an opportunity to re-evaluate and improve.

Before tackling a tech debt task, it’s wise to ask if the original requirements still make sense. With the passage of time, user needs and business goals evolve and we should adapt our solutions to serve them better. Additionally, collaboration is key. By working closely with product, design, data, and testing teams, we ensure that our updates and changes aren’t just about patching old and outdated functionalities, but also about innovating and staying relevant.

Faced with increasing maintenance challenges, our team paused to reevaluate our mobile application. We identified potential improvements, like adopting a dedicated API and the backend-for-frontend pattern.

However, we chose to investigate further before making changes, questioning whether our app’s structure aligned with our product vision and how it affected user pain points. This inquiry extended beyond engineering, involving user experience experts and product managers.

We discovered that our app’s structure was limiting our ability to deliver on new strategic features and some existing features such as payments would be hard to evolve. This collaboration led to a novel strategy: a gradual rebuild of the app with technologies and an architecture that support dynamic content and enhanced payment options.

The new application is now live, and we are able to update content faster and provide a more robust payment experience for our users. By engaging cross-functional teams, we enhanced value and streamlined future engineering efforts.

Don’t get too attached to code

Just as writers are proud of their publications, us engineers can feel closely tied to the code we spend a lot of time and care to write. However, this attachment might, consciously or unconsciously, make us resistant to change. Furthermore, if the code works we might even be scared to touch it in case we break something.

As an example, it was a very proud moment for the company and the engineering team when we ran our first deal through our external API. The first deal, Ecoslops, which was run in France in 2021, marked a structural change in the ability to raise capital in a follow-on in France.

After a successful release, it was very tempting to keep the code as is and not touch it for fear of introducing bugs. However, working with our broker partners and gathering usage data from the subsequent deals we’ve identified the need to expose deal documents through the API and improve the developer experience to facilitate onboarding of new broker partners.

We have since deployed a second version of our API and launched a developer portal. If we were to rely on our early success and stay on the first version and the API, it would be harder for us today to onboard new patterns. But most importantly we would be doing a disservice to the investor by not allowing them to access all information they could get.

One effective strategy for managing code attachment is to actively mark and manage tech debt as it arises. Recording tech debt tasks or embedding direct annotations in the code, such as `// TODO JIRA-1234: Refactor for Payments Service integration`, not only highlights specific areas needing improvement but also facilitates tracking and systematic resolution. Acknowledge that tech debt is inevitable and look out for it.

There is always tech debt, if you don’t see it, maybe you are not looking hard enough.

Every software system has parts that could be improved. By diving deeper and understanding our systems from various angles, we can identify these weak spots.

Ask the right questions

Here is a non-exhaustive list of questions to ask yourself about the code you are working on:

• Are there some design patterns applied and if so, why?
• Do I properly understand the context surrounding this code?
• Do I understand the overall software architecture my code is part of?
• What are the parts of the code that everyone is afraid to touch? That could be a great place to start for a new team member, someone with a fresh pair of eyes and a good way to gather valuable knowledge.
• What are the parts of the system that often break?
• Do I understand the trade-offs made when this code was written?

When you get in the mindset of actively asking questions about what the system is trying to achieve and why, it’s easier to remember that our code is just a tool. And it makes it easier to let go of the beautiful (or not so beautiful) code we wrote a few years ago. The broader goal is always about delivering value to our users and our business. Keeping this perspective helps us be open to beneficial changes.

Think of the future

Today’s latest code becomes tomorrow’s old news. But this shouldn’t discourage us. Instead, it should promote forward-thinking.

Embrace the idea that change is inevitable. When we code with future changes in mind, we’re not only addressing today’s challenges but also preparing for tomorrow. This mindset pushes us to write better code by structuring our code neatly and continuously learning the latest best practices.

Every piece of tech debt we address is a lesson. It offers insights that can guide our future decisions. With this mindset we’ve made changes to improve our API performance to prepare us for higher volumes of demand. We were able to make those changes with a high level of confidence because we already had a good level of automated tests.

Get the business on board

While the technical aspects of addressing tech debt might be evident to developers, the business side of an organisation might need a little more persuasion. Here’s how to frame tech debt in a way that resonates with business stakeholders and moves them out of the “if it ain’t broke, don’t fix it” mentality:

The conversation should be framed in terms of business value, there is no need to deep dive into the technical details, unless you wish to bore your non-technical audience. Instead explain how reducing tech debt can lead to faster delivery times, fewer bugs, and a more stable product.

The concept of risk and the importance of mitigating it are generally understood. To drive the point home you can give real life examples of consequences of ignoring tech debt. Most people would understand that taking your vehicle to be serviced is crucial to the good functioning of the vehicle and ensuring the safety of its passengers. The same applies to software systems. Some pieces of code will need to be updated, some will need to be replaced.

Make sure you also come prepared with a clear plan of action and the effort required. You don’t have to present it as a one time task either. Splitting it into smaller tasks phases can make it more manageable. It’s easier to plan, prioritise and include it into the development process. Once the business is on board and you get to implement the changes, make sure to measure the impact of changes. Once the business is on board and you get to implement the changes, make sure to measure the impact of changes.

Consider our recent shift to a monorepo. Previously, different teams managed their own repositories, leading to fragmented practices and making cross-team contributions difficult. This setup hindered company-wide pattern implementation and complicated custom build and deployment processes.

To persuade the business side, we outlined a streamlined plan for transitioning to a monorepo. This approach focused on unifying our development processes and simplifying pipeline management. Post-migration, the benefits were significant. We not only streamlined our deployment pipeline but also seamlessly integrated observability and instrumentation across services. This migration, initially undertaken to address tech debt, ultimately enabled broader improvements and operational efficiencies, illustrating the tangible benefits of tech debt resolution to our business stakeholders.

Conclusion

Tech debt, often viewed as a challenge, carries hidden opportunities. Every piece of code we type today will age, but that’s the nature of the tech world. By embracing change and viewing tech debt as a chance to learn and improve, we ensure that our systems remain resilient, user-friendly, and in line with current needs. So, the next time tech debt pops up on your task list, see it as an opportunity to innovate and stay ahead in this ever-evolving digital age.

Author: Irénée Ajeneza, Staff Software Engineer at PrimaryBid. Irénée has over a decade of expertise building software systems in the finance, marketing, and logistics sectors. His passion for technology is matched by his commitment to continuous learning and his enthusiasm for sharing his knowledge with peers.