If you've done any amount of programming, you would eventually, inevitably, feel the urge to rebuild everything.
The reason programmers feel this way, is that reading someone else's code is always harder than writing your own from scratch. There are some good situations where doing a full re-write is a good idea, but the vast majority of situations, it is a terrible, terrible idea.
Every developer who has spoken to any other developer would notice that there is always the feeling that a code re-write will solve all the issues of an old project; people swear that the new version will be well-planned, documented, etc but you know what it won't have? The 90% of the time that was spent to fix the last 10% of unexpected issues. That is, all the effort that the previous developer spent to debug, test, and hack their way through bugs.
That is why I like to approach existing code like a surgeon, and the application is my patient. A surgeon theoretically knows how a patient's body and organs should work, but sometimes she'll start surgery, and the patient's innards are a mess. Maybe they had a bone breakage in their youth that repaired badly, or their liver isn't quite positioned the right way.
Now if the surgeon's original task is to remove a kidney stone, would she take out and re-organise the rest of the innards to match her textbook? Of course not, the patient's only complaint was the kidney stone, and was perfectly healthy in every other way. The body would have adapted and hacked its way to function like normal.
There are some instances where a code rewrite is warranted, and likewise we can use the surgery approach. If the patient above not only had kidney stones, but also exhibited other convulsing and or other symptoms due to the bad positioning of the badly-healed bone or upturned liver, then sure - it would be a good idea to explore fixing the rest of the organs.
I'm so gross. What's for lunch?