Seeing a lot of people say that a rewrite is a terrible idea, but (as someone who doesn’t understand why) I’d love to hear a more fleshed out explanation re: why exactly that’d be a bad idea.
It can be difficult to fully replicate the existing system and there are frequently important but subtle reasons why the existing system has the architecture it does.
To the extent that one can make modular changes and address the most-important pain-points, one probably should.
Sometimes a complete rewrite is a better choice, but if embarking on that path, a fail-fast attempt at an MVP might be the right style to do so. If the MVP crushes the existing system in performance/benefits, then subsequent iterative development may yield a viable re-written replacement system.
- The ultimate reason: it will take too long and be over budget. The business will (rightfully) ask why should they invest x amount of capital just to get essentially the same feature set back. Businesses do not care about whats under the hood.
And here is why: - the rewriter team usually does not fully understand edge/corner cases that the current mess handles, but obscures it.
- the rewrite inevitably ends up following the same patters that the original did leading to unusual/weird cases
- rewrite teams get too ambitious and attempt to over abstract and over engineer, eventually creating another mess understood by only them
In addition, if you don't change the development conditions, you're likely to end up with a similar mess at the end. Sometimes, code is messy because you didn't know what you were doing when you started and a rewrite could help; but sometimes code is messy because the requirements are messy and change rather a lot --- a rewrite can't help much with that.
That doesn't mean never do a rewrite, but you've got to have a pretty good reason, and it sure helps to have an incremental plan so that you don't end up with two systems and so that you start seeing the fruits of your labor quickly.