Software Entropy and the Strangler Fig: Surviving a 20-Year-Old Codebase

Right now, I find myself fighting a three-front war.

Front one is keeping a 20-year-old behemoth of a B2B application alive. We are talking about decades of legacy ASP.NET and VB.NET where two decades of tweaks, patches, and "temporary fixes" have become permanent, load-bearing pillars of the architecture. Every time I touch it, it feels like playing Operation with oven mitts on—spending 90% of my week untangling logic just so a simple bug fix doesn’t cause a ripple effect that crashes a critical service.

Front two is modernizing the architecture. I am actively trying to implement a rudimentary Strangler Fig pattern—slowly carving out legacy functionality and pushing it into a clean, testable shared library project so we can actually run proper unit tests and stop the bleeding.

Front three is modernizing the team. While keeping the lights on and quietly rebuilding the engine, I am also pushing a retraining effort to get my peers up to current framework versions and embracing programming LLMs and agentic development tools right inside Visual Studio.

Keep the app alive. Modernize the code. Modernize the skillset. All at the exact same time.

It is an exhausting balancing act, and lately, the sheer friction of dealing with that legacy codebase has brought me to a boiling point. I’ve started asking the scary question that inevitably arises in these scenarios: At what point do we stop this endless chain of tweaks, execute a full, top-down review, and just admit it might be time to toss it all and start a clean rewrite?

If you are feeling this frustration, you aren't alone. It is one of the classic, defining dilemmas of mature software engineering. While there isn't one "magic number" that dictates when you should stop, there are several established concepts that help define exactly what that threshold looks like—and what you should do about it.

The Problem: When Software "Rots"

The first concept you are feeling is Software Entropy (often called Software Rot).

Borrowed from physics, software entropy states that systems inevitably trend toward disorder and complexity over time unless energy—in this case, deliberate refactoring and care—is actively applied.

In a system that has seen 20 years of continuous tweaks, software entropy is often off the charts. The original architecture, if there ever was one, has been lost. The design intent is buried under years of "special case" logic that developers felt too nervous to challenge, so they just added another if statement.

This entropy leads directly to the core threshold: Technical Debt Bankruptcy.

"Technical debt" is the implied cost of rework that occurs when a team chooses an easy solution now instead of a better approach that takes longer. We all carry some. But Technical Debt Bankruptcy happens when the "interest payments" on that debt—the hours spent fixing regressions, deciphering old code, and writing complex tests to protect brittle functions—finally consume your entire development budget. Developer velocity drops to nearly zero because the team is entirely occupied with just keeping the legacy system alive.

If your 20-year-old system is in bankruptcy, continuing to tweak it isn't just frustrating; it’s an irresponsible misuse of resources. A structural intervention is non-negotiable.

The Danger: Why the "Big Rewrite" Is Usually a Trap

Your instinct at this threshold is to declare war on the old system. "Stop everything!" we want to shout. "Let's do a ground-up, top-down rewrite and get this right once and for all!"

This brings us to a famous cautionary principle. Joel Spolsky, a major voice in the software industry, called the big, ground-up rewrite "the single worst strategic mistake that any software company can make."

Why?

1. The Hidden Knowledge Problem: The old, ugly codebase, despite its entropy, works. It represents years of hidden knowledge: hard-earned bug fixes, obscure corner cases, and critical business logic. If you rewrite from scratch, the new system will almost certainly fail to handle dozens of edge cases the old system solved years ago.

2. The Second-System Effect: Coined by Fred Brooks, this is the trap where developers working on the replacement tend to over-engineer it. They try to solve every problem the old system had, plus every theoretical future problem they can think of, resulting in a system that is bloated, complex, and years late.

The Solution: Meeting the Threshold with a Strangler Fig

If continuing to tweak is bankruptcy, but a total rewrite is suicide, what is left? A top-down review is essential, but it must be a review focused on strategic, gradual replacement.

This is exactly why I'm pushing the Strangler Fig Pattern.

Popularized by Martin Fowler, this strategy is named after a type of fig tree that grows from seeds planted high in the canopy of a host tree. As the strangler fig grows, it sends roots down, gradually encasing the host. Over time, the host tree dies, and the strangler fig is left standing as a tree in its own right.

Here is how you survive the three-front war using this pattern:

Review the Boundaries, Not the Internals: The top-down review shouldn't be about the messy legacy code, but about defining the clean API boundaries and shared libraries that will eventually wrap the system.
Redirect New Work: Build all new features in a modern, testable architecture.
Migrate Incrementally (and Agentically): Identify low-risk, critical pieces of functionality and methodically rewrite them into the new library. This is where upskilling the team pays off—using AI coding assistants to quickly translate and refactor legacy logic into modern framework standards accelerates this process exponentially.
Route Traffic: Use a proxy layer to direct calls to the new modern services.
Retire the Legacy: Over time, the new system grows and replaces the old piece by piece until you can safely delete the 20-year-old "host" code.

The Way Forward

The truth is, that legacy system is a shackle, but trying to smash it all at once with a Big Rewrite will almost certainly crush your team under the weight of lost knowledge and over-engineering. The Strangler Fig pattern provides the structural pathway out of technical debt bankruptcy, but you cannot navigate that path with yesterday’s skills.

I challenge you to look at your team's readiness today. If you aren't training them on modern versions of your target framework and empowering them with agentic development tools right now, you will never have the velocity needed to strangle that 20-year-old monster. AI isn't just for writing new greenfield code; it is your essential force multiplier for analyzing, translating, and safely refactoring your way to freedom.

Add custom speed settings to your ifit map workout

Ifit.com allows you to build a workout walk/race/bike route simply by clicking on a Google Maps interface. You can then use a compatible ifit-enabled workout machine to recreate the route automatically. The problem is that the user interface still isn't final, so there are features in place that aren't exactly obvious. For example, if you create a workout your machine starts at 1 MPH, because that's the default. But how to set it to start at say, 3 MPH? Easy, just switch from map view to graph view: That button switches from the Google Maps interface to a chart that allows you to visualize and control effort: You can't change the elevation, this is fixed due to the geography that you selected. But you can drag the yellow (speed line) to change the speed of your device. What if you want to have segments at different speeds? Easy, just click and drag and it will break the line, and you can drag each segment of the line independently: ...

The Insomniac Coder

Search This Blog