Examples of second system syndrome(coliveira.net)
coliveira.net
Examples of second system syndrome
http://coliveira.net/software/what-is-second-system-syndrome/
6 comments
This is a perfect example of how to do a re-write: bit by bit, always keeping the existing system running.
It's fundamentally different from a re-write from scratch, and in effect much closer to refactoring.
There's no black and white choice between re-writing and refactoring.
It's fundamentally different from a re-write from scratch, and in effect much closer to refactoring.
There's no black and white choice between re-writing and refactoring.
It's important to note that some of the smartest people in the world are vulnerable to this. People we all respect. Fredrick Brooks accused himself of making this mistake. He came up with a job processing language for the 360 and in his book he claims it is the single worst programming language ever invented.
I'd also suggest that RDF has been the second system for Tim Berners Lee.
I'd also suggest that RDF has been the second system for Tim Berners Lee.
The article somewhat misrepresents Netscape's attempted rewrite. I was at Netscape at the time, although I never worked on the rewrite.
>The solution Netscape found was to rewrite the whole browser from scratch, in order to create a new code base that would be easier to evolve.
It is true that the Navigator codebase was hard to work in, but the rewrite had another big motivation: it was in Java. One of Netscape's strengths was that Navigator was cross-platform: Win32, Win16, MacOS, and various Unices. The problem was that it was getting hard to find anybody to work on anything but Win32--in particular, MacOS was perceived as a dying platform, and developers were fleeing. So the idea was that Javagator would let us move forward with just a few specialists on each of the minor platforms.
(Of course, looking back, expecting reasonable performance out of Java that decade may have been pretty stupid. There was a project underway called Electrical Fire, which I think became, or fed into, Sun's first JIT; but we probably shouldn't have assumed it would succeed.)
>In the case of Netscape versus Microsoft, Netscape gave up all the development advantage they had.
This is just flat-out wrong. For it to be true, Netscape would have had to have essentially everybody working on Javagator; we definitely didn't. I think it was something like 5-10 people at most.
>The solution Netscape found was to rewrite the whole browser from scratch, in order to create a new code base that would be easier to evolve.
It is true that the Navigator codebase was hard to work in, but the rewrite had another big motivation: it was in Java. One of Netscape's strengths was that Navigator was cross-platform: Win32, Win16, MacOS, and various Unices. The problem was that it was getting hard to find anybody to work on anything but Win32--in particular, MacOS was perceived as a dying platform, and developers were fleeing. So the idea was that Javagator would let us move forward with just a few specialists on each of the minor platforms.
(Of course, looking back, expecting reasonable performance out of Java that decade may have been pretty stupid. There was a project underway called Electrical Fire, which I think became, or fed into, Sun's first JIT; but we probably shouldn't have assumed it would succeed.)
>In the case of Netscape versus Microsoft, Netscape gave up all the development advantage they had.
This is just flat-out wrong. For it to be true, Netscape would have had to have essentially everybody working on Javagator; we definitely didn't. I think it was something like 5-10 people at most.
One appeal of a rewrite is that you can do it properly. I think this is based on the misconception that just because you created something, you understand it.
In fact, we build software (or grow it). Where we end up is more like where an explorer ends up in an unknown region. Very few people prove even one aspect of a small part of their programs, and it takes them a long time. We understand our code no more than we understand our bodies.
There's no need to make an effort to rewrite, because with the next disruptive platform, the same old stuff all gets rewritten/reinvented anyway (current egs: JavaScript (web); objective-c (iPhone)).
BTW: Joel's famous article on mozilla: http://www.joelonsoftware.com/articles/fog0000000069.html
In fact, we build software (or grow it). Where we end up is more like where an explorer ends up in an unknown region. Very few people prove even one aspect of a small part of their programs, and it takes them a long time. We understand our code no more than we understand our bodies.
There's no need to make an effort to rewrite, because with the next disruptive platform, the same old stuff all gets rewritten/reinvented anyway (current egs: JavaScript (web); objective-c (iPhone)).
BTW: Joel's famous article on mozilla: http://www.joelonsoftware.com/articles/fog0000000069.html
In my various projects, we've decided to rewrite quite a few large components, and we've never regretted a single time (yet).
We've regretted continuing work on horrible code bases though.
When you have hindsight, stronger developers, and more understanding of the performance and requirements, you truly can do a better job.
We've regretted continuing work on horrible code bases though.
When you have hindsight, stronger developers, and more understanding of the performance and requirements, you truly can do a better job.
"What's so great about your new software?"
"Its big, slow, late and expensive!"
"Its big, slow, late and expensive!"
The thing with re-writes is that you only really hear the horror stories because people like to talk about failing companies that stemmed from something technical. The good re-writes never get much press, and neither do the companies that slowly fade to black. I think SAS could end up going that route if they don't completely rewrite their systems and introduce a more friendly coding system.