Every software engineer knew, surest to his bone, how to do it right. After all, he did the first version and fixed all those bugs that came the years. He has been bothered by all those bad decisions that caused him hours of late night work. Had he had the chance to do it from scratch. It would be perfect.
Everyday, he sees the mess that is and think of the perfection that could be. Most likely there is nothing he can do, since he has jobs to do and the code belongs to the company. If he was lucky, he got to participate the project that would actually do it. That will be like opium for the addicted.
Those who studied the history of computer would be too familiar with stories like this. They would know that the first team were as smart as the second, the third, or the fouth. Re-writing is usually like growing-up. The likely outcome is most likely the same as the previous attempt.
It is the irresponsibility of the senior manager to launch a “re-do” project without knowing what exactly would have made a difference. Re-writing is not the right way to clean-up the old mess or to save maintenance costs. It is justified only when the existing architecture has truly run of steam. Even then the project must be done with extreme caution. Backward compatibility is tricky and usually demands the same kludges that caused the original mess.