Is It Time to Rewrite From Scratch?
/Congratulations! You had an idea for a business. You hired a few software developers to implement your idea. You got your product out the door or started offering your service to the world, and it took off. Now that you've got a successful business up and running, it's time to think about growing and maintaining it.
Now you're faced with a crucial question: do you try to grow and maintain the version of your software that you already wrote, or do you throw it away and rewrite it from scratch?
It can be a tricky question, especially if the team which initially built it isn't around or if they're inexperienced. If you were in a hurry to get to market, you may have incurred a lot of technical debt. You may have hastily added and removed features as you learned more about your problem domain. Maybe you had to hastily on-board some new developers or consultants toward the end of the project to meet your deadlines. None of these are incorrect decisions, but one of their side effects may be a code base which is kind of a mess. And now you're wondering if the best course of action might be to rebuild everything from the ground up, cleanly, without the blind alleys and vestigial features.
Or maybe what you're operating off of now was a prototype that the original authors never intended to put into production; a proof-of-concept that isn't architected to be stable or scalable. You hired some developers to prove that your idea was workable so that you could take it to investors; now you're wondering whether you can turn that prototype into a production system, rather than incurring the costs of rewriting it.
If the code base is a completely unmaintainable mess, scrapping it might very well be the best course of action. But there are some pretty strong arguments to be made against throwing it all away and starting over. That messy code base has a lot of knowledge and bug fixes packed into it. But all that knowledge might be useless if it's inscrutable to new developers, or if the code is so tangled and brittle that making changes is difficult, risky, or simply impossible.
What you really need to know at this stage are two things:
- How maintainable is it?
- What will it take to make it maintainable enough?
If the original developers are still available and they are sufficiently experienced, they can probably give you an honest answer to those questions. I say "probably" because developers are human, and subject to human foibles. They can be overly optimistic or pessimistic because they're too close, too emotionally invested in the software. Or they may simply be loathe to admit mistakes. Or they may be overly eager to start from scratch and "get it right this time".
If the original developers are gone, or if they're simply not very experienced, you may just not have anyone in your organization who can accurately answer these two questions.
This is where a third-party code audit comes in. An unbiased assessment of your code by someone who has no agenda, no attachment, no stake in your decision. A code audit can tell you whether or not you have maintainability issues and recommend a course of action to correct any you may have.
Once you have that, you can make an informed decision about whether or not it makes sense to start over to or to continue with your current code base.
Interested in a code audit? CodeWise can help!