According to this they have to lock out access to certain frequencies and power levels in order to get FCC certification. If those lockouts are implemented in the firmware, that means closed firmware.
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.
And their argument right back at em: Having programmed for S60 Nokias, I know S60 Symbian has tight support for DRM. And Microsofts track record suggests windows mobile does as well. So why open up to an 'insecure' plateform while so many DRM safe/certified/secured/insertmeaninglessdrmstatement platforms do not get supported?
Probably, but in the process awareness has been created for choice in operating systems. I bet most people here in the netherlands never knew what an operating system was because it was just "how the computer works". Now people start to realize there is a difference between a computer and a windows. Perhaps this will make it a little bit easier for Linux advocates to explain what linux actually does.
In Holland Specialisterren (hmm, sounds familiar) does the same.
According to this they have to lock out access to certain frequencies and power levels in order to get FCC certification. If those lockouts are implemented in the firmware, that means closed firmware.
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.
And their argument right back at em: Having programmed for S60 Nokias, I know S60 Symbian has tight support for DRM. And Microsofts track record suggests windows mobile does as well. So why open up to an 'insecure' plateform while so many DRM safe/certified/secured/insertmeaninglessdrmstatement platforms do not get supported?
Probably, but in the process awareness has been created for choice in operating systems. I bet most people here in the netherlands never knew what an operating system was because it was just "how the computer works". Now people start to realize there is a difference between a computer and a windows. Perhaps this will make it a little bit easier for Linux advocates to explain what linux actually does.