Without any offense intended, the decision to rewrite a codebase from scratch is a common, and serious management mistake newbie software developers make.
There are many disadvantages to be wary of.
- Rewrites stop new features from being developed cold for months/years. Few, if any companies can afford to stand-still for this long.
- Most development schedules are difficult to nail. This rewrite will be no exception. Amplify the previous point by, now, a delay in development.
- Bugs that were fixed in the existing codebase through painful experience will be re-introduced. Joel Spolsky has more examples in this article.
- Danger of falling victim to the Second-system effect — in summary, “People who have designed something only once before try to do all the things they “didn’t get to do last time”, loading the project up with all the things they put off while making version one, even if most of them should be put off in version two as well.”
- Once this expensive, burdensome rewrite is completed, the very next team to inherit the new codebase is likely to use the same excuses for doing another rewrite. Programmers hate learning someone else’s code. No one writes perfect code because perfection is so subjective. Find me any real-world application and I can give you a damning indictment and rationale for doing a from-scratch rewrite.
Whether you ultimately rewrite from scratch or not, beginning a refactoring phase now is a good way to both really sit down and understand the problem so that the rewrite will go more smoothly if truly called for, as well as giving the existing codebase an honest look to really see if a rewrite’s needed.