Comment Re:The prefect blueprint? (Score 2, Insightful) 184
Joel makes some good points but also some very bad ones. I'll give him that a big project takes long to rewrite and gives the competition a chance to leap ahead. You'll have to find a way to deal with that. I'll also give him that many programmers tend to suffer from the NIH syndrome (what he calls "code is harder to read than to write" which is only true if the code really is a big mess that does needs a rewrite or if the developer trying to read it is really inexperienced). I'll also give him old code has been tested and the standing bugs are known (no, they are not fixed because that cannot be done in the old codebase unless you're willing to throw a lot of time/money at it). But that is in no way reason to dismiss a rewrite.
He claims the "hairs are bugfixes". In my experience, they're not. A lot of bugfixes tend to only remove code and leave a cleaner total behind. The "hairs" are features for users that were necessary to implement in order to remain competitive but weren't in the design when programming began. Those features are usually loved the most by users and tend to grow with additions, leaving a big mess. This can only be solved by changing the design fundamentally to enable the features in the core which usually require a rewrite of most components.
He claims code doesn't rust. Well, it does. The features i mentioned above are one way in which code rusts. Another is the platform the code runs on evolves. OS API calls used by the project may become deprecated if a new version of the OS is released. I'll admit that it takes a while before the changes are really pushed through so the rewrite becomes necessary.
Then (i promise i'll stop after this one) he claims "there is absolutely no reason to believe you are going to do a better job than you did the first time". He says there is not "more experience" because the team of programmers changed. Well, maybe the team did change, but all the bug reports from the last version are neatly integrated in the Test Plan. We're talking about a big commercial software project, right?
I'm not saying you should "just" do a rewrite from scratch, the pros and cons should be well considered. But totally dismissing it like Joel does, saying the programmers are wrong and the code is fine, is not considering it very well in my opinion.
He claims the "hairs are bugfixes". In my experience, they're not. A lot of bugfixes tend to only remove code and leave a cleaner total behind. The "hairs" are features for users that were necessary to implement in order to remain competitive but weren't in the design when programming began. Those features are usually loved the most by users and tend to grow with additions, leaving a big mess. This can only be solved by changing the design fundamentally to enable the features in the core which usually require a rewrite of most components.
He claims code doesn't rust. Well, it does. The features i mentioned above are one way in which code rusts. Another is the platform the code runs on evolves. OS API calls used by the project may become deprecated if a new version of the OS is released. I'll admit that it takes a while before the changes are really pushed through so the rewrite becomes necessary.
Then (i promise i'll stop after this one) he claims "there is absolutely no reason to believe you are going to do a better job than you did the first time". He says there is not "more experience" because the team of programmers changed. Well, maybe the team did change, but all the bug reports from the last version are neatly integrated in the Test Plan. We're talking about a big commercial software project, right?
I'm not saying you should "just" do a rewrite from scratch, the pros and cons should be well considered. But totally dismissing it like Joel does, saying the programmers are wrong and the code is fine, is not considering it very well in my opinion.
