The conversation on DDL has recently turned to GNOME 3.0 and what magic number that means. There are some strong opinions that a complete rewrite will be a mistake. I agree completely, but I had to try an experiment to truly believe.
In the GNOME 2.9 development cycle I decided to rewrite Same GNOME. I needed to rewrite the graphics sub-system anyway and many parts of the UI needed upgrading to a modern API. So I figured that the remainder wouldn’t be a big problem and that I would end up with cleaner code. I was wrong.
One of the killers with a rewrite is time. I did get the rewrite done with most, but not all, of the new features I wanted and no feature regressions before the feature-freeze. However, the new features received virtually no testing. GNOME 2.0 also had this problem.
New bugs aren’t a problem – not the normal things we call bugs anyway. There have been very few serious crasher-style bugs in the code. The complaints have almost all been about the UI (e.g. the animation makes the game too slow for some people, or they hate the grid colour). I can easily check that the code doesn’t crash, what I can’t easily check is what people other than me want.
In hindsight the effort would have been better spent on incrementally changing the code-base. There was a lot of code that just didn’t need changing. Even the idea that a complete rewrite will get rid of all the design problems and half-baked patches isn’t correct: I still screwed up several parts of the design and there are still places where I did something because it was easy-to-write, not because it was the best way to do it. The only real change in code quality is that most of these are now marked with “FIXME”.
The extra time spent levering new code and even new designs into existing code is far less than the time you spend rewriting all the code that still works.