Fresh graduates often push for a rewrite at the first sign of complexity, because they’ve spent the last four years in an environment where codebase lifetimes are measured in weeks. After their first unsuccessful rewrite they will evolve into Junior Engineers, repeating the parable of Chesterton’s Fence and linking to that old Joel Spolsky thunkpiece about Netscape3.
Be careful not to confuse this reactive anti-rewrite sentiment with true objections to your particular rewrite. Remind them that Joel wrote that when source control meant CVS.
3. The real reason Netscape failed is they wrote a dreadful browser, then spent three years writing a second dreadful browser. The fourth rewrite (Firefox) briefly had a chance at being the most popular browser, until Google’s rewrite of Konqueror took the lead. The moral of this story: rewrites are a good idea if the new version will be better.
The Joel article bugs me for a number of reasons, and the fact that his core example is totally demonstrably historically wrong is one of them.
Rewriting software is something you should only do if you can answer the question, “Why will it be better this time?”
New programmers to a code base think the answer is “because the last people working on this were idiots.” Sometimes that’s true! If you’re inheriting, e.g., some PHP code written by people who weren’t really web developers but just learned by copy-pasting, you might be smarter-enough to have a rewrite work. However, that’s the exception, and typically, you’re not any smarter than the people who wrote the code in the first place, so you’re not going to do any better.
Another answer that’s possible but unlikely to be correct is “they made bad technology choices.” Yes, some technology choices really are so bad that correcting them can make a difference, but moving, e.g., from Rails+MySQL to Node+Mongo is unlikely to make things better.
A good answer is “the business requirements they built this product for no longer apply.” For example, Microsoft Office vs. Google Docs or iTunes vs. Spotify. The former product in both cases is more robust, more complete, technically capable of doing it all, but the latter product by virtue of not having to do things that are no longer necessary can be radically simplified.
Anyway, John Millikin is correct: no haunted forests!