Should I Do A Total Rewrite?

Short answer…

No. It’s probably a bad idea. Rewrites are expensive and error-prone and almost never necessary. Contact me for options.

True story…

I had a phone call recently with someone who needed some advice. Their site was slow and needed a few new features. They were neck deep in a multi-year, very expensive rewrite of their primary — and profitable — web presence. Why? Well, when it came right down to it, they weren’t sure. Their contractor told them that the technology in use was old (that was true); that the site would be faster after the rewrite (likely true); that future updates would be easier (maybe true). Here’s the thing. It’s also true that this client could have saved a ton of money by not doing the rewrite and they could have had the new features they wanted as well.

Instead of a rewrite…

The speed problem could have been addressed a couple of ways. One way would be to simply throw more hardware at the problem. This is not a silver bullet but it can work in many cases. And servers are cheap. You can rent them from a service provider for as little as $5 a month now. Another way would have been to analyze the existing software for bottlenecks and do spot improvements to those areas. I’ve never met a website that couldn’t be sped up significantly just by changes in the software. This is often tricky work and can sometimes take a while to do but I’ll always recommend this first over a total rewrite.

And the new features? You can create any feature with any language or underlying tech platform. A rewrite is rarely necessary. If you ever ask if a feature is possible and your developer says no then you might want to start looking for a new developer. Sometimes it’s very expensive. In some cases it may take a long time. But it’s always possible. (Unless you’re asking to create a robot army. I always say no to robot armies.)

Addressing the issues in those ways would have saved this client tens of thousands of dollars.

Why are rewrites bad?

It’s partly economics and partly that programming is very hard. The primary cost of any software — whether it’s a website or robot artificial intelligence — is maintenance. Once you’ve written software, it must be updated. There are always new features and bugs to fix. Always.

Rewrites will not solve your maintenance problem. You will still require ongoing maintenance for the life of the application. Maybe the maintenance will be cheaper but I doubt it. It’s like roads. You can add more lanes but that just attracts more cars so you’ll always have traffic.

Rewrites often introduce new bugs. Part of a rewrite is to copy the old functionality to the new software. This actually provides two opportunities to create new bugs. First, the new software could be written incorrectly. Second, the old software has lot of code that was added over the years to handle special cases and fix specific problems. Remember when you hired that person last year to fix that one weird thing? It’s in the old software, somewhere. If that isn’t copied exactly then you might have that old weird problem again in the future.

Rewrites often create new or modified workflows for your staff. That means new training and documentation.

Rewrites can take a huge amount of time. Months. Years. During that time you’ve got to keep the old software running as well. Rewrites can take so long that you’re forced to make updates to the old software while you are doing the rewrite. It can be a nightmare.

Sometimes a rewrite is the right move. Maybe you’re using a software framework that has become obsolete or is no longer receiving security updates. Maybe you lack the expertise/time/money required to keep it up to date yourself or that expense is greater than the cost of a total rewrite. Maybe the long-term cost of maintaining your old software is too high and after analysis you’ve decided that a rewrite will be a net savings. Maybe the contractor who originally wrote the app really was terrible and created a barely functioning garbage pile. Maybe you just want to and you have the time and money to do it. In those cases, do the rewrite!

But sometimes developers (in-house and contractors) want to upgrade just because they want to upgrade. One reason is that it’s boring to work on old tech. New tech is exciting and fun and allows them to add something to their resume. (In-house developers always need to keep up with current tech — feed and care for your devs by giving them training opportunities.)

Contractors will sometimes say that something needs a rewrite just because they don’t want to put in the effort to understand the old code. It’s easier to understand something that you’ve written yourself. Especially if you’re in a long line of contractors who’ve been maintaining the same code. I’ve come into plenty of situations where I’ve inherited an app that’s been rewritten three times by three different contractors for no good reason.

So what do I do?

Sometimes a rewrite is the right move. It might save you money or time or headaches. Often it’s not necessary or can at least be safely postponed. It’s a decision that needs to be analyzed and considered carefully. Let me know if I can help.