Technical Debt Decision Making: Refactor, Rebuild, or Stand Pat

Software development is costly.

Introducing a seemingly high-value new feature to your product can present substantial challenges that test the mettle of your development teams.

Consider the time investments necessary for feature development, the inevitable troubleshooting of unforeseen issues (often surpassing initial estimates), and the frequently underestimated aspect of ongoing code maintenance.

Data indicates that an astonishing 70-80% of the total lifecycle costs of a software application are attributed to maintenance alone. This statistical insight underscores the importance of an often-underestimated aspect: ongoing code maintenance.

What's more, when code is delivered without a keen focus on quality, it worsens the problem significantly, substantially increasing the complexity of your teams' work. This leads to a considerable accumulation of technical debt within the codebase.

At some point, a pivotal decision must be made: continue to manage the existing code, undertake a comprehensive code refactoring project, or embark on a complete rebuild of the product?

How Did We Accumulate So Much Technical Debt?

Technical debt is a familiar concept in software development. It emerges when developers take shortcuts or compromise to meet pressing project deadlines or immediate deliverables. 

Every product's codebase naturally collects some technical debt, which is normal and not necessarily a problem. However, issues arise when this debt keeps piling up over time and slows down the velocity of software development. This slowdown reorients the focus from innovation and feature enhancement to issue resolution. 

This shift means that a disproportionate amount of developmental bandwidth is allocated towards 'firefighting' rather than advancing the product roadmap.

So, what contributes to the accumulation of technical debt within a software development lifecycle? 

Foundational Decisions

Just as a solid foundation is crucial when building a house, the decisions made during the initial phases of software development have a lasting impact on the project's trajectory. Choices concerning software architecture or technology selection are strategic imperatives. If these decisions aren't made correctly from the start, they might lead to substantial challenges as the project evolves.

Initial architectural decisions may not exhibit immediate drawbacks, especially in smaller teams.  However, as the scope of the project broadens and the size of the development teams scales, these initial decisions can gradually evolve into primary bottlenecks. They may inhibit workflow efficiency, obstruct seamless communication, and escalate operational costs. Eventually, it can reach a point where releasing even a simple software feature becomes a substantial challenge and a source of significant frustration for the product teams.

Poor Approach Towards Quality

A lack of commitment to clean and quality code is dangerous.

Similar to the regular maintenance required to preserve the value of a sturdy house, software quality demands continual attention. A lapse in this commitment can convert software from a strategic asset to a burgeoning liability.

Some product teams may not fully grasp the consequences of subpar quality. They lack quality assurance mechanisms or best practice quality frameworks integrated into their operational procedures.

However, more commonly, teams recognise the implications of low quality but often lack the authority to prioritise quality improvements over the pressing need to deliver the next set of features. They work under the pressure of impending deadlines, which makes it challenging to shift their focus towards enhancing quality. There's often the false optimism that the following month will provide the bandwidth for quality improvement initiatives, yet more often than not, things get even worse.

These scenarios often highlight a disconnect between the "business" and "technology" aspects, where technology teams tend to follow the business directives. While business stakeholders understandably pursue feature expansion as a strategic goal, such a focus often deviates from the path of investing in the reduction of technical debt.

Desire For More Features

New features are exciting. They enhance the product, enrich user engagement, and increase its core value.

But did you know that every new feature, regardless of its code footprint, carries associated and often underestimated overheads? It entails added efforts for testing, maintenance, and bug fixing. And not to ignore, it increases the overall complexity of the product and demands more mental effort from the product team to maintain the entire codebase.

Think of it like buying another coffee machine. While it enhances your daily routine, it also requires regular maintenance to operate at peak performance. And if you make the wrong choice, or if you fail to maintain it regularly, it becomes more clutter than a useful addition to your household.

Strategic Decision-Making Amidst Mounting Technical Debt

When you are at the stage when there is a lot of debt accumulated in your codebase, you find yourself at a critical decision-making vertex. The weight of each choice you make is inescapable, carrying significant implications for both your product teams and broader business objectives. 

So, what strategic options should you consider?

Option 1: Maintain The Status Quo

You have the option to retain the current situation. This may translate to zero immediate financial or time investment. While this route may appear cost-effective on the surface, it carries the risk of stagnation or even deterioration as your project or team scales.

You might identify some low-hanging fruit - easy-to-fix issues. While addressing these issues can bring some positive changes, the fundamental problem will likely persist, and the overall impact may be limited.

Retaining the status quo can be a strategic move under specific circumstances, such as when your product is approaching the end of its lifecycle or requires minimal ongoing maintenance, remaining stable with infrequent updates. Alternatively, it can be a suitable option when you're nearing a significant milestone, like a new investment round or a major product launch. In these instances, delaying decisive action on underlying issues could be justifiable as a short-term strategy.

Option 2. Prioritise Refactoring Over New Development

Another scenario involves code refactoring, which means renovating and improving the codebase.

This approach works well when executed cautiously. Without the discipline to delay or slow down the pace of new feature development, extensive refactoring can lead to unfavorable outcomes. It carries inherent risks, and if not carried out with care, it can introduce numerous new issues into the product.

The benefit of this approach is that, if successful, it leads to an enhanced codebase. It also offers the flexibility to choose which parts of the codebase to refactor, eliminating the need for a complete rebuild.

This option is most appropriate when you've identified a specific foundational issue that doesn't require a full codebase rebuild. For example, it could involve breaking down a large component or resolving a performance bottleneck at the interface level.

Before starting any renovation initiative, conduct an initial assessment of the effort and associated risks. Sometimes, refactoring a single component of the software can have a profound impact on the entire product. Refactoring a database, for instance, can have ripple effects across the entire product, even if it initially appears to affect only one part. In fact, the more modular and higher quality the code, the smoother the refactoring process becomes.

Option 3: Parallel Rebuild And Migration

It might seem overwhelming, but when dealing with a product of exceptionally low quality, opting for a complete rebuild is often the most practical solution. In fact, it can frequently be a simpler and cleaner choice than extensive refactoring.

While it does require an investment, projecting the costs of rebuilding and maintaining a high-quality solution over a five-year period typically yields a more favorable outcome compared to persisting with and maintaining a low-quality codebase or refactoring it.

The positive aspect of this approach is that building a new product can occur in parallel with ongoing development. This can involve a dedicated team focused on the new product, which is a much cleaner and more productive approach. It presents the opportunity to make the right architectural decisions, leverage the most suitable technological stacks, and modernize the product.

However, it's essential to remember that once the new product is ready, the migration process comes into play. Be prepared: migrations are substantial projects on their own and require a serious commitment.

Strategic Imperatives For Mitigating Technical Debt 

None of the options listed above are straightforward; they bring risks and financial commitments and may decrease the team morale. After all, who would naturally gravitate towards the difficult task of refactoring over developing an innovative and shiny new feature?

The most effective strategy lies in preventive action—averting a scenario where such a complex decision becomes necessary. Here’s how you can do that:

Quality Awareness

Understanding that a low-quality product can have adverse effects on your business is the essential starting point.

However, ensuring a high-quality product is not solely the responsibility of the technology teams; it should be a company-wide mindset. Cultivate a culture where your product managers and stakeholders prioritize quality while pursuing new developments without compromising it.

Resisting the urge to cut corners in the face of pressing deadlines is undeniable. Remember, shortcuts must be the exception rather than the rule. Frequent reliance on shortcuts might bring exponential costs over time.

Support your product development team with the tools and best practices to seamlessly integrate quality into their work. Doing so elevates the standard of excellence consistently across your product and technological offerings.

Thoughtful Architectural Decisions

Unwise architectural choices have the potential to undermine the success of your product, even when you have a team of top-tier developers producing high-quality code. The foundational structure of a product is not easily altered in the future.

When setting up the fundamental architecture of your product, it's crucial to approach this task with great care, weighing the advantages and disadvantages of different options. Rather than focusing solely on the current state, consider the product's future growth. Opt for solutions that can scale and adapt as your product expands. Ensure comprehensive documentation of your decisions and the rationale behind them.

While it's impossible to guarantee a completely future-proof solution, making well-informed choices significantly reduces the risk of costly errors.

Maintain A Lean Approach

Approach product development with a lean mindset. A product free from unnecessary clutter is easier to manage, visually appealing, and more user-friendly.

Resist the temptation to introduce a new feature solely because it seems like a good opportunity or because one of your customers has asked for that.

Instead, aim for a balance, focusing on truly essential features. Prior to incorporating new features, ensure their necessity is supported by data. Embrace experimentation and validation before committing the product development team to a two-month project, followed by three times the effort for ongoing maintenance.

This lean-centric approach should be embraced on every level of the organization—from executive strategy-making and sales initiatives to product management's feature-value assessments and the software development team's quest for efficiency and optimal performance.

Final Thoughts

Let's acknowledge the inevitable: attaining absolute certainty against future renovations is an unrealistic goal. Technologies evolve, past decisions may misalign with the new strategic objectives, and significant migration projects may still be required. Yet, by following diligent preventative measures, you can significantly reduce the risks and be better prepared when challenging decisions become unavoidable.

---

Before you leave

Decisions regarding code refactoring, rebuilding, or maintaining the status quo can significantly impact your organization's future.

Take that proactive leap and avoid standing at a costly crossroads by subscribing to my newsletter, where I regularly provide valuable insights on building and scaling products. 

Share this article with others. By doing this, I’ll collect more questions from readers and ensure more relevant articles.

Thank you,

Marina