Not understanding the system is rarely a good reason to rewrite it. Let me guess, the system they rewrote was Google Groups? Because I remember back in 2006 it was working perfectly. Now their search of Usenet posts can hardly find anything.
Anyhow, I was working on a system once which had a very crappy implementation. Thousands lines of code in each source file. Spaghetti code everywhere. I spent a lot of time fixing bugs in that system. Clearly it wasn't productive. I decided to completely rewrite it. Spent a couple of months working on it, but when it was done, it had a cleaner implementation and far fewer bugs. I noticed that I hardly spend any time on that system any more - an indirect indication that the decision to rewrite was the right one.
Fast forward two years. I moved on to other projects. A new guy comes along (senior than me actually). His task is to make the old system work with new requirements. He comes with an idea - a complete rewrite. Since I worked on that system before, I get to review his design. He explains to me how his new implementation is going to have various "new" features. Then I ask him if he knows that the existing implementation does all that already and more. He had to admit that he have no idea how the existing system works, so he doesn't want to touch it - thence the desire to rewrite.
I gave him my advice but he proceeded with the rewrite anyway. The old code obviously got scrapped. Now, looking back I can't see where his new code ended up. Most likely his rewrite failed, so the new implementation never saw the light of day.
The moral of the story: even if you don't like the old system, you have to understand how it works in order to create something better.
Wow. So when you rewrite something, it's perfectly justified. When someone else decides to do the same thing, you twist the argument around on its head. Sounds completely hypocritical, mate.
Rewrite without deep understanding is bad. alexeiz claimed that the original implementation was bad, but still tried to work on it and decided to rewrite it, in the end, to something he considers clean, and as such, a good work base. The next guy did not even try to work with it, even though alexeiz seemed to have clear ideas on how to implement it on his system (which is, two years later, quite a good indicator of the sanity of the thing). You did not read that carefully, did you ?
Nope, because you have to understand in depth the existing work in order to rewrite it properly. Then only good rewrite is when you understand the existing stuff enough to see what is wrong with it. You can't rewrite something if you don't know what it does.
Anyhow, I was working on a system once which had a very crappy implementation. Thousands lines of code in each source file. Spaghetti code everywhere. I spent a lot of time fixing bugs in that system. Clearly it wasn't productive. I decided to completely rewrite it. Spent a couple of months working on it, but when it was done, it had a cleaner implementation and far fewer bugs. I noticed that I hardly spend any time on that system any more - an indirect indication that the decision to rewrite was the right one.
Fast forward two years. I moved on to other projects. A new guy comes along (senior than me actually). His task is to make the old system work with new requirements. He comes with an idea - a complete rewrite. Since I worked on that system before, I get to review his design. He explains to me how his new implementation is going to have various "new" features. Then I ask him if he knows that the existing implementation does all that already and more. He had to admit that he have no idea how the existing system works, so he doesn't want to touch it - thence the desire to rewrite.
I gave him my advice but he proceeded with the rewrite anyway. The old code obviously got scrapped. Now, looking back I can't see where his new code ended up. Most likely his rewrite failed, so the new implementation never saw the light of day.
The moral of the story: even if you don't like the old system, you have to understand how it works in order to create something better.