Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
Is it a bad idea to rewrite code or an entire system? At some point, developers want to rewrite for various reasons. Often, it’s because we simply don’t understand the existing codebase or think it’s a tire fire. But is the benefit there? Sometimes, yes. Sometimes, no. It’s a pretty nuanced topic around cost/benefit.
YouTube
Check out my YouTube channel, where I post all kinds of content accompanying my posts, including this video showing everything in this post.
Rewrite
When it comes to software development, the debate over whether to rewrite code never ends. Some developers always want or have the urge to rewrite existing code they stumble upon. Many experienced developers will tell you to avoid rewriting at all costs. But as someone involved in significant rewrites, I believe there’s more to consider. Let’s dive into the complexities of this decision, particularly how it relates to coupling within your codebase.
The advice against rewriting often stems from the wisdom shared by Joel Spolsky over two decades ago.
It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don’t even have the same programming team that worked on version one, so you don’t actually have “more experience”. You’re just going to make most of the old mistakes again, and introduce some new problems that weren’t in the original version.
He pointed out that the worst strategic mistake a software team can make is to decide to rewrite code from scratch. This warning resonates deeply, especially since starting anew offers no guarantee that you’ll do a better job than before.
Reflecting on my journey as a developer, I recall countless moments early in my career when I felt compelled to rewrite portions of code or even entire systems. Often, this impulse arose from ignorance; I didn’t fully understand the existing codebase and mistakenly assumed it was flawed. However, the truth is that a blank slate may seem appealing, but it can be deceptively easy to overlook the complexities and edge cases that exist in the original code.
One of the most imporant aspects to remember is that with experience comes an understanding of the intricacies of your system. If you’ve spent years in a particular domain, you likely have a wealth of domain knowledge that can guide your decisions. This knowledge enables you to identify the real value within your existing codebase. If you find that the current implementation truly is a ‘tire fire’ holding back progress, then perhaps a rewrite is warranted.
This brings us to the concept of “worse is better.” In software development, it’s often the case that a simpler, more limited solution can be more user-friendly and effective than a complex, feature-rich one. The 80/20 principle applies here: 80% of the value often comes from just 20% of the code. If you can focus your rewrite on that critical 20% while simplifying the overall system, you might just end up with a better product.
Never underestimate the value of working software
The decision to rewrite should ultimately come down to a cost-benefit analysis. What are the costs associated with the rewrite? What benefits do you expect to gain? Sometimes, the technology gap can be a compelling reason to consider a rewrite. If your current technology stack is outdated and stifling innovation, it may be time to modernize.
Greg Young shared an insightful experience from a project that involved rewriting a prototype that had gone into production.
However this is still a naive viewpoint. What really mattered was that after our nine months of beautiful architecture and coding work we were making approximately 10k/month more than what our stupid production prototype made for all of its shortcomings.
We would have been better off making 30 new production prototypes of different strategies and “throwing shit at the wall” to see what worked than spending any time beyond a bit of stabilization of the first. How many new business opportunities would we have found?
After nine months of development, the new system was only generating marginally more revenue than the original. He concluded that they would have been better off creating multiple iterations of the prototype to explore different strategies rather than investing so much time in a complete overhaul.
Additionally, it’s important to challenge the notion that older technology is inherently bad. I’ve integrated with two third-party services that perform the same function; one is a modern solution, while the other is an older system built in ColdFusion. Despite their differences, both systems deliver equivalent value to users. The age of the technology doesn’t necessarily dictate its effectiveness.
My Experience
My own experience with a major rewrite involved a system I had been part of for six to seven years. We ultimately decided to undertake a rewrite because of a significant technology gap—our system couldn’t effectively integrate with online payment methods, which was increasingly essential in the e-commerce landscape of the early 2000s. This necessity justified the effort to rebuild.
So, should you rewrite? The answer is not a simple “no.” Context is King, and each situation is unique. It involves a lot of factors and to weigh the benefits of a rewrite against the risks involved.
Join CodeOpinon!
Developer-level members of my Patreon or YouTube channel get access to a private Discord server to chat with other developers about Software Architecture and Design and access to source code for any working demo application I post on my blog or YouTube. Check out my Patreon or YouTube Membership for more info.