I disagree. Rewrites are risky because you're changing code that has been working for some time. It is easy to introduce bugs into a sufficiently complex system when refactoring.
"The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it." - Joel Spolsky
parent is right in that when you realize there's significant functionality that is not captured in the requirements, then it's it's good idea to NOT REWRITE... when you end up reverse-engineering requirements from an existing app, you're standing near a bottomless pit of other horrors you can't even fathom... that's not gonna be an only 200% miss-etimate! think in the range of 10x (order of magnitude) difference between actually and real effort, and how many corners will need to be cut and personal time sacrificed to get from 10x to a "management acceptable" 2-3x overtime during the rewrite.
You don't want to live in this hell during the rewrite, trust me!
(Oh, and another tip: if your management authorizes the rewrite you propose easily, it means you are SEVERELY UNDERPAID... the time of good devs always costs to much for rewrites to be worth it, unless the dev cut a really bad deal on hiring)
I doubt Joel Spolsky was equating legacy code with technical debt in this quote. Not all technical debt is robust and well tested legacy code.
Chromium for instance has code from the original KHTML written in the 90s, most of that remaining code is reasonable and makes sense today. If it didn't someone would have replaced it.
"The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it." - Joel Spolsky