If you’re reading this, it probably means you’re currently involved in a software project that’s a steaming hot mess, and you’re looking to explore your options. Don’t be embarrassed. This is a safe place; we’ve all Googled “Should I completely rewrite my software system?” at some point.
And to be fair, the idea of completely starting from scratch, in theory, can sound incredibly tempting when the software you have isn’t ideal.
It’s got bugs up the wazoo, breaks from time to time, doesn’t scale well, the code is ugly, and the framework isn’t maintained anymore. We’ve all been there. It might feel a bit like wading through a vat of molasses — slow, monotonous, and cumbersome. A rewrite of your software systems might seem like the best solution to all your problems.
Hey, we get it. We’re programmers, designers, creators, and architects, and the first thing we want to do when we get to a site is to bulldoze the place flat and build something bigger and better. We’re not excited by incremental renovation but instead thrive off of great change and innovation. It’s kind of our M.O.
But is rewriting your entire software system a good idea? Is it really the best way to achieve what you’re trying to accomplish, or will it actually end up hurting your business’ efforts?
Over two decades ago, writer Joel Spolsky spoke to this idea when he put Netscape on blast for rewriting their codebase. In his landmark essay, “Things You Should Never Do," Spolsky famously said that “the single worst strategic mistake that any software company can make” is deciding to rewrite code from scratch.
Why is that?
To help answer that question, we put together a list of the five most significant reasons why rewriting your software systems could be bad for your business.
1. FEELING THE NEED TO CHANGE SOMETHING JUST TO CHANGE SOMETHING ISN’T SUFFICIENT
As developers, we understand that urge to make significant changes and add convenience to our working environments. But trying to fulfill that urge is not always the best choice. In fact, it can actually be detrimental to your overall project goals.
No matter how tempting it might be to throw away all the dumpster-fire code that has become temperamental with age, the risks of throwing away something that works can be more significant than the potential wins. Your engineering team has to seriously discuss the pros and cons before making such a big decision.
2. A REWRITE MIGHT SIGNIFICANTLY DELAY THE RELEASE OF THE PROJECT
Arguably, the most common problem associated with a software system rewrite is that it takes significantly longer than expected. Companies have deadlines for their releases which are important to follow. Even if the current state of the application code is terrible and the engineers can build something much better, rebuilding everything will take time, and companies might not have the time to invest in a rewrite. Plus, the time spent rewriting could be used to make your current setup more polished. That’s what we like to call efficiency, baby!
3. MORE BUGS AND LESS FUNCTIONALITY
Not only does a complete software rewrite often take longer than expected, but losses in functionality are a common side-effect.
Why is that? Well, to start, all of those small but important features like tweaks and bug fixes in the original product don’t always get reimplemented during the rewrite.
Even the best developers write buggy code — as many as 50 bugs per 1000 lines of code. That’s a lot. Moreover, historical data suggests that a sizable percentage of those mistakes won't even be found before you deliver the application. Rather, they’ll pop up like a game of Whack-a-Mole later on. That’s a surprise no one wants or needs.
4: SOFTWARE SYSTEM REWRITES ARE EXPENSIVE
Most straight-ahead application rewrites start with an honest belief that the requirements will exactly match the existing application in order to expedite development, keep testing simple, and, of course, keep costs low. But much like your friendly neighborhood mechanic who says, "Since we gotta yank the tranny we might as well replace the clutch and change the rear main seal," the temptation to sneak in a few minor "as long as you're changing that" improvements is almost impossible to resist. A change here, a difference there, and pretty soon there goes your budget.
Plan on spending between $6 and $23 per line of code you write, from start to finish. It’ll require more than basic arithmetic to add all that up.
5. REWRITING A PROJECT DOESN’T GUARANTEE ANY SUCCESS IN ITSELF
Any developer who deals with ugly legacy code might think that the grass will be greener on the other side. Chances are, though, those things will get even worse if the project is rewritten. It can be tempting to throw away old technologies and start using something new and fancy, but that in itself is not a guarantee of any success.
You can use the fanciest of technologies out there. Still, if you lack solid software engineering skills, you might build a codebase that’s worse than the current one. Technologies are nothing but tools that need to be used properly. Like any tool, if you can’t handle it, you’ll do more damage than good.
There is no cut-and-clear answer to whether a rewrite is the right way to go. It depends on a whole bunch of factors and requires carefully weighing needs, budget, time, and more. But as a rule of thumb, rewrites should generally be avoided as much as possible no matter how tempting they are because of the significant risks that come with them.
Instead of running away from the problems in your codebase by throwing everything away, fix them. You can create great products with older technologies if you use solid engineering skills.
Speaking of solid engineering skills...Inventive has a team of incredibly talented developers who are interested and excited to talk with you about your product development needs. Contact us today and let’s chat!