August 27, 2024If you lead engineering or software development within your enterprise, you know that you walk a shaky tightrope between maintaining your existing systems and pushing forward with new innovations. Balancing technical debt and new feature development is no easy feat — sure, you have to service technical debt, but you also have to develop new features that keep your business competitive. It’s a delicate dance that many engineering leaders face, especially those working within large enterprises with complex legacy systems. So… how do you do it?
We obviously can’t speak for everyone, but here’s how we think through balancing tech debt and innovation:
Technical debt refers to the implied cost of additional rework caused by choosing an easier, limited solution now instead of using a better, more comprehensive, or more future-compatible approach that would take longer (or might cost more in the short term). In simpler terms, it’s the trade-off between getting something done quickly vs. doing it the right way. Now, we all know sometimes you just have to do whatever it takes to put out an immediate fire — we’re not casting judgments here if you’ve incurred some technical debt. But over time, this debt can accumulate, creating significant obstacles to future development.
As an engineering leader, it’s your responsibility to strike the balance between paying down this debt and pushing forward with new features. This is no easy task, especially when you’re dealing with systems that are deeply embedded in your organization’s operations. The key question is: How do you maintain the integrity of your systems while also fostering innovation?
One of the things I see time and again when a developer encounters technical debt: “We should rewrite this from scratch.” Soooo many times if devs encounter legacy code they don’t like, it’s a “tear it down to the foundation and rebuild it right!” kinda situation.
Don’t you dare do it.
Well, at least don’t just take their word for it without digging a lot deeper.
Every line of code in your system has a history, a reason for being there — much like the old saying about Chesterton’s fence: “You don’t take down a fence until you know why it was put up.”
Every existing line of code is hard won. It’s hard won through analysis and architecture and design. It’s hard won through bug reporting. It’s hard won through user experience, and user complaints, changes in business rules, etc.
Developers (and even CTOs) are often really bad about respecting those hard won lessons.
You have something that works. The first question you should be asking is not “can I replace it with something better?” The question should be, “can I make use of what’s already here (and working) within a better framework?”
When tackling technical debt, I truly believe the best line of code we can write is no code at all.
Whenever and wherever possible, we try to augment or assist existing code that works instead of trying to rewrite it. I cannot stress how many times we’ve been called in to rescue a project because a new CTO or Sr. Developer wants to put their stamp on a project or company, decides to rewrite everything from scratch… and breaks, well, everything. (Not that we don’t want the project rescue business, we’d just prefer things get done right the first time for everyone involved…).
Instead of rewriting everything from scratch, consider whether you can leverage the existing code within a better framework. This approach not only saves time and resources but also minimizes the risk of introducing new bugs or system failures.
So let’s say you do respect your existing code… you want to tackle your technical debt little by little… now what? Well, you gotta understand the risks first.
While we certainly support paying down technical debt, rushing to do so can lead to significant disruptions, especially if the process isn’t carefully managed. One of the things I see far too often is the creation of dual systems — where part of your operation runs on legacy systems, while new features are developed on a new platform. This almost always leads to increased complexity and operational inefficiencies.
One of the worst things you can do as a CTO is spend time and money replicating existing functionality… and a lot of paying down technical debt is exactly that.
Instead of diving headfirst into a full rewrite, consider whether smaller, incremental changes might achieve your goals with less risk.
Moreover, managing the risk of disruption is just as important as managing the technical debt itself. You’re balancing those three aspects of continued feature development versus paying down that technical debt versus the risk that emerges from both of those. But, the risk of doing nothing is also significant, as legacy systems become increasingly brittle over time.
So, how do you balance maintaining those legacy systems and hard-won code with the need for new development? One effective strategy is digital decoupling. This involves creating a layer of abstraction between your legacy systems and new development efforts. By wrapping your existing systems in a “box” and putting APIs in front of them, you can build new features on top of these abstractions without disrupting the core system.
This approach allows you to pay down your technical debt in stages, gradually moving logic and functionality over to new systems without a massive, disruptive overhaul. By doing this, you’re paying down your technical debt in very, very tiny stages.
We talked about a lot of the risks associated with paying down technical debt, but there are also clear scenarios where it becomes necessary. For example, when your system’s architecture becomes so convoluted that adding new features is virtually impossible, it’s time to consider a major overhaul.
Another critical factor is security. Legacy systems often have outdated security protocols that leave your organization vulnerable to breaches.
Poor security is just uncaptured liabilities. It’s on your balance sheet, you just don’t know it. When security risks become too great, addressing technical debt is not just a good idea — it’s essential.
Lastly, consider the end-of-life (EOL) for your technology. If you’re relying on software or platforms that are no longer supported, it’s time to move on. This might not always be an easy decision, especially when the legacy system still functions. However, the long-term costs of maintaining an unsupported system—both in terms of money and talent—often outweigh the benefits.
At a certain point, it just becomes economically unsupportable.
The goal of any engineering leader should be to balance innovation with stability. While new features are essential for staying competitive, they shouldn’t come at the expense of your existing systems. By taking a measured approach — respecting legacy code, using digital decoupling to manage technical debt incrementally, and carefully considering the risks — you can maintain this balance.
As you move forward, keep in mind that there’s no one-size-fits-all solution. The best strategy depends on your specific situation: the complexity of your systems, the urgency of your business needs, and the resources at your disposal. But with careful planning and a clear understanding of your goals, you can successfully navigate the challenges of balancing technical debt with new feature development.
If you’re in a situation where you need to accurately asses when it’s time to pay down that debt, when it’s time to invest in new features or tech, our Innovation Lab is a great place to start. Whether it’s project rescue, increased clarity, or just peace of mind, we can help you figure out where to start, what to end, when and how.
Jeff Francis is a veteran entrepreneur and founder of Dallas-based digital product studio ENO8. Jeff founded ENO8 to empower companies of all sizes to design, develop and deliver innovative, impactful digital products. With more than 18 years working with early-stage startups, Jeff has a passion for creating and growing new businesses from the ground up, and has honed a unique ability to assist companies with aligning their technology product initiatives with real business outcomes.
Sign up for power-packed emails to get critical insights into why software fails and how you can succeed!
Whether you have your ducks in a row or just an idea, we’ll help you create software your customers will Love.
LET'S TALK