The Pitfalls of the Big Rewrite: Why Evolution Often Beats Revolution

In many conversations about how products and systems evolve within companies, a recurring theme emerges: the pitfalls we encounter. One of the most significant is the pattern of the major rewrite, sometimes called “building off to the side.” Now, don’t get me wrong – a well-executed strangler pattern can lead to amazing transformations of codebases and products. However, embarking on a major rewrite can also be the first step towards building a company’s own tombstone.

(Disclaimer: Yes, I’ve been involved in both successful and failed transformations. It’s crucial to remember that beyond the technical aspects, the health of the business, the state of the market, and the broader economy are where any conversation about such significant undertakings needs to begin – these factors determine the capacity for disruption.)

One often-underestimated side effect of greenfield development is the migration. This term can cover a lot of ground: it might be as simple as users needing to click in a new place, customers switching to a new API endpoint, or new workflows delivering familiar data in a different sequence. But it can also be a noisy, troublesome process involving new passwords, different accounts, and widespread confusion.

Why is this disruption so critical? Because a product’s effectiveness often lies in its usage becoming a habit. Think about knowing instinctively which button to press and when, or walking the same route with your dog while absorbed in your phone, barely noticing your surroundings until you arrive home.

Habits, put simply, are formed through repetition as our subconscious takes over the process. One strategy for breaking a bad habit is to introduce friction. Eating too much popcorn at the movies? Try using your non-dominant hand. Doomscrolling before bed? Put the phone to charge in another room. This same principle applies when a system you rely on completely changes the interface you’ve grown accustomed to – friction is introduced, breaking your established workflow habit.

Reading about habit formation, one book highlighted how incremental changes contribute to product success. A great comparison is the Segway versus the Electric Scooter. One is now largely a niche item (often seen carrying tourist groups), while the other is a widespread success. Why? The electric scooter builds directly on the familiar paradigm of a child’s scooter, offering similar mobility but with a much lower learning curve, leveraging an existing habit.

Reflecting on this often brings to mind that popular image representing the pinnacle of “doing it right in agile” – the evolution from scooter to bicycle to motorbike to car.

While I agree that delivering value incrementally is generally the better approach, this specific analogy highlights a potential issue if taken too literally for user experience: our customer is forced through significant changes with each leap – from riding a scooter to balancing a bike, and so on. In this interpretation, we are constantly breaking the user’s habit and forcing adaptation to a new interface. While change underlies all improvement and some discontinuity is natural, it’s vital to consider the unintentional discontinuities we might be pushing onto customers and how we can minimize them.

Beyond the user, we must also consider the engineering discontinuity. Developers often crave the new and shiny, eagerly embarking on large rewrites. We sometimes fail to recognize these as failures even when, three years later, they haven’t fully replaced the original system. Or consider when we describe something as “the old-new thing” because our supposedly pristine green field already has a patch of dying grass in the back corner. We consistently underestimate the impact the “unknown unknowns” of a new stack will have. We build exciting new streaming architectures only to spend far more time than anticipated figuring out the nuances of Kafka disruptions, recovering from human error, or dealing with the downstream impact of switching to React on our APIs.

All these challenges divert attention from the actual goal and inevitably delay our estimates. This is often coupled with the endless scope creep encouraged by business partners who hear statements like, “With this new architecture, we’ll have more flexibility!” In my experience, this flexibility, combined with the allure of newfound freedom from legacy constraints, often invites the urge to build a completely new experience rather than continuing to build upon the existing one, leveraging established user habits and maximizing the current user experience.

Concluding, the evolution of software is undoubtedly tricky. We are often biased by our desire for the new and our rejection of what we label “Legacy code.” This bias can lead us towards fresh starts that overlook the business’s capacity to absorb such a restart or endure an extensive period with no new feature deliveries. I believe we should all more carefully analyze our options, giving serious consideration to the incremental approach of improving existing software. The hope is to provide the business with enough continuity to allow us, over time, to further evolve the system towards the engineering excellence we strive for.