SaaS product rewrite? A bad idea?

Should you rewrite your SaaS product from the ground up?

No

Now, before we prod and poke at the No, let’s try and understand why this question deserves so much attention if the answer is so cut and dry.

What is a rewrite?

The traditional idea behind a rewrite is to save an old product which is slogging due to technical debt. To put it another way, when your SaaS application is no longer working efficiently because its growth was messy and not thought out. A clearer way to identify whether your product needs rewriting is to see whether your product is still serving the best ideas. For instance, do not fashion a pencil into a pen, it’s far easier and more prudent to make a pen designed to serve the purpose, from the ground up. That being said, a rewrite isn’t a decision you take lightly. The work involved is colossal.

Why do we feel the need for a rewrite?

Let me see if I get this right, back in the day you had your “big break” idea. A small set of developers and perhaps, the founder too, worked their asses off to bring the concept to life in the form of an application.  Your honeymoon phase is long over, and you have with you a decent app and a bunch of loyal customers. You keep improving the application, adding new features, fixing bugs. All this while the competition is growing and you need to up your game. Those small tweaks don’t cut it anymore and might as well get that new feature and more since your customer base is loyal and growing.

Today, you ask yourself if you’ve been doing it right, did you go for the right platform, can your application scale, did you outsource to the right developers? You contemplate whether a rewrite is called for to start afresh. Let’s dignify this with proper bullet-pointed reasons you’ve come up with for a rewrite:

• Your new team of developers finds it hard to maneuver around the shoddy coding. The moment you fix a particular issue, three more crop up.
• The product leaders want to reinvent or rather redo the wheel.
• The platform your application is built on was not the right choice, to begin with.
• Your developers have you convinced the market won’t forgive this mistake going further.
• Your team is a lot more experienced and understand the problems a lot better now since they are familiar with their customer requirements and the features they need to incorporate, they can architect the app perfectly this time around. They demand a chance to redo.

I’m sure you can come up with a lot more excuses, sorry, reasons to justify the need for a rewrite. For who doesn’t love the idea of wiping the slate clean and doing it all perfectly the next time around.

Why your developer will disagree with this conclusion?

Firstly, developers and product leaders dramatize the value you get by doing a rewrite while most of them grossly underestimate the effort and money required for a rewrite of whatever magnitude it may be.

When your developers tell you the code is a mess, it could be because:

• There are architectural issues, in other words, the factoring of the code was not done right. You can fix all architectural problems without having to throw your code away. Pull one programmer out of the mix and have him work at this by creating sensible base classes, moving things around and introducing sharp interfaces between modules, so as not to disrupt ongoing projects.
• The code could be inefficient or slow. To tackle this issue optimize your code by rewriting particular parts, not the whole thing.
• The code was written in a shoddy manner. Convention wasn't followed while naming, so it takes double the time to make sense of it all. There are tools to solve this and starting over is not a solution.

Why it’s a bad idea

It’s a really bad strategic move to rewrite the code from scratch. Some companies continue to work on their old code base while building a new product, this could lead to a financial disaster but not strategically wrong. You still have a fallback here.

Developers are architects at heart. It'll be hard to find an architect excited about a renovation project as much as building a new project from the ground up. Fixing bugs here and there, adding a new feature or two are all small increments to an existing project, build perhaps by their predecessors. A lot of programmers have themselves convinced that the existing code is a mess, most often than not, they’re wrong. See, they have forgotten to take into consideration a fundamental law of programming.

 It’s easier to write code than to read it.

This makes reusing code hard. Imagine having to read pages and pages of coding, not being able to make sense of what half the API calls are for. Most, don’t see the advantage of “old” code. This code has stood the test of time. It’s been tested, the bugs have been fixed, there’s nothing particularly wrong with it. Coming back to the API calls, some of them might exist to fix bugs for that might no longer be a problem today, like having to install on a PC without Internet Explorer or to fix bugs that crop up while installing files on your floppy disk.

When you choose to throw away all this code, you’ve chosen to throw away the effort and research behind finding these pesky bugs and fixing them. You’re throwing away issues that were found and fixed after real-world usage. You’re throwing away years of programming you paid good money for. You’ve just lost a two or three-year head start on your competitors, which is the equivalent of a decade in software years. That might’ve been a tad dramatic. Still, it’s a long time.

This means you end up pushing old code to your loyal users, unable to incorporate new features necessary to stay relevant in today’s market since you don’t have code which is shippable. You’ve just spend enormous amount of money rewriting code that already exists.

To summarize:

• It will take an insane amount of time to complete.
• While you are redoing the wheel, the markets keep evolving. Competitors will close the edge you previously had, and your users might just migrate.

Conclusion

Starting over doesn’t necessarily mean you’ll do a better job this time around. If you have a new team, they might even end up making the same mistakes again on top of introducing new mistakes. A software isn’t like your old car or metal which gets worn down and rusted. Those years of experience has made your code wise, in a sense. If it’s a cleanup you're looking for, refactoring could do the job for you. Hope this proves useful.