I have heard this tale from prospective clients dozens of times. See if it sounds familiar:
"We recently hired a new developer. They say that we need to rewrite our entire code base because the previous developer did a poor job and the code is unmaintainable. They say the current architecture is bad. They can make the product way more reliable, faster, and better. All they have to do is rewrite the code from scratch.
Our new developer says it will only take a few months. Once they're finished, our business will be able to depend on the new code base for years to come. The developer says that we can't support new customers without a rewrite because the entire system is about to crumble."
I’ve become so familiar with the “must rewrite” story that I almost dismiss it outright every time. Here is my translation of the story:
"My new developer doesn't care to understand my current product. He thinks he can build a similar product that he does understand, and of course he believes that he will do it better than the former guy. He'd rather build a new thing that matches the way he thinks about code than figure out a working system that was built by someone who thinks differently."
This is not universally true, but it is my default interpretation. I have recommended rewrites in several situations, but I’ll get into that in a moment.
Convenience
Now, I don’t believe developers are being intentionally dishonest or lazy when they propose a rewrite. But a rewrite is not easy: it’s convenient. There’s a huge difference.
I say it’s convenient because it requires that a developer learn nothing about code that they are struggling with. The client bankrolls a few months of their time, they get to build something they feel good about, and—in their mind—all those pesky problems of yesterday will simply disappear.
But the truth is that a rewrite trades one set of problems for another. Perhaps today your system is sluggish. A rewritten system may improve performance. However, that rewritten code may not capture all of the business rules or capabilities you enjoy in the current system.
The developer likely believes that they will easily deliver all of the existing benefits of the current system with none of the trade-offs, but that rarely works out as planned. A 2-3 month rewrite quickly balloons into 5 or 6 months. Each time the developer says they’re about finished, you or they find some additional business requirement that the rewritten code base has simply missed.
A book analogy
Think of it this way: you have a favorite book. You’ve read it a dozen times. You know every major plot point, the characters, and so on. But do you recall every single detail in the story? Every article of clothing, the scenery, the dialogue within the side stories told along the way? Probably not.
Could you rewrite your favorite book from scratch? You may come close and keep all the major events straight. But what about all of the nuances that make the story interesting? I would wager that you probably won’t end up with the same book at the end of your rewrite. You will likely be disappointed with the result.
So it is with code. There is virtually no chance that your developer will rewrite your entire code base and fully capture all of the business requirements handled by your existing code base.
Outward pessimism, inner optimism
I assert that your developer knows this! The developer has not memorized the code base, and has likely told you that there are problematic sections of code that they can not even understand. In fact, they are unlikely to even read all of the code (tens or hundreds or thousands of lines of text), let alone comprehend it all. And if they have an aversion to working in the code, the chances of them using the existing code as a reference to preserve your business requirements are slim-to-none.
Your developer likely believes that the previous developer simply did a poor job and that, given enough time, they can do better. They’re pessimistic about the previous developer’s work and optimistic about their own.
I recently pointed out this behavior to a client when asked to give a second opinion on a rewrite recommendation. The client had engaged a new overseas development team. Within a matter of weeks, the team strongly recommended a complete rewrite. In my review, I determined that a rewrite is not necessary. The team had identified true problems with the code base, but I felt that a rewrite was an extreme solution to a series of relatively minor and completely manageable problems. I explained that there is a difference between a dilapidated house and a house that is “lived in”. This house was lived in.
When does a rewrite make sense?
All of that said, there are certainly times when a rewrite makes sense. The most typical justification I give for a rewrite stems from a fundamental limitation imposed by past technology decisions. For example, we have one client whose previous developer rolled their own authentication and authorization solution. It was inherently less secure than standard solutions and tightly coupled to every single API endpoint. Another client’s data-centric product supported two-way syncing. The syncing process failed as often as it succeeded due to a highly convoluted syncing strategy that did not match the business’s requirements. We have a third client whose platform was built on top of a now-unsupported open source framework that only runs on a programming language version that is far past end-of-life (the maintainers have stopped offering security updates). All three of these clients are better served by rewrites that eliminate these fundamental problems, even if it means we may introduce new (solvable) problems in our rewrite.
In all three of those pro-rewrite examples, our team spent significant time in the original code bases prior to recommending a rewrite. Additionally, all three code bases presented obvious problems to the clients and their end users. The notion of a rewrite did not come from out of the blue: instead, we communicated the problems faced in development, identified the impact that the problems had on the business, and attempted to improve what already existed. We used what worked for as long as we could until the trade-offs stopped making sense.
If a new developer reviews your code base for the first time and concludes that a rewrite is necessary, it probably means one of two things: either (1) the code base is so fundamentally bad that the product doesn’t even work, or (2) the developer would really just prefer not learning how the code works. The former is worth investigating. The latter justifies finding a new developer.