5 ms·

Examples of second system syndrome

24 points by coliveira 16y ago

JoeAltmaier 16y ago
"What's so great about your new software?" "Its big, slow, late and expensive!"
3pt14159 16y ago
For some positive examples look to FreshBooks. They were stuck with horrible, horrible spaghetti code for years, then they decided to implement a portion of it slowly with Python. They made this all work by keeping the Python portion of the project very clean and strict (massive test coverage, very modular, very consistent) and had the existing PHP talk to it. Slowly but surely they were able to rip away the horrible parts. As a side effect the PHP layer ended up getting much cleaner. It was the opposite of the broken window syndrome. Another positive aspect about having a stable multi-language system was that when they really wanted to use a library from a third language they were comfortable just wrapping it up in a thin API and proceeding like normal. 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.
- rickmb 16y ago
  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.
  - Retric 16y ago
    Another approach is the Windows NT rout. Where you develop a competing product to your core product and then expand it's capabilities until it replaces your core product.
    - sitmack 16y ago
      That cost MS hundreds of million dollars in development and lost opportunities. You can only do that if you have no competition. If they had added USB support to NT4 we wouldn't have needed to go to win2k. Really MS, NT4 can't support USB? They should have evolved NT4 rather than fork it into the win2k -> xp -> vista mess. They could have had the worlds best UNIX but internal dogma forced them piss in their own watering hole.
lkrubner 16y ago
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.
6ren 16y ago
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 http://www.joelonsoftware.com/articles/fog0000000069.html
metageek 16y ago
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.
Peaker 16y ago
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.

24 points by coliveira 16y ago

"What's so great about your new software?" "Its big, slow, late and expensive!"

For some positive examples look to FreshBooks. They were stuck with horrible, horrible spaghetti code for years, then they decided to implement a portion of it slowly with Python. They made this all work by keeping the Python portion of the project very clean and strict (massive test coverage, very modular, very consistent) and had the existing PHP talk to it. Slowly but surely they were able to rip away the horrible parts. As a side effect the PHP layer ended up getting much cleaner. It was the opposite of the broken window syndrome. Another positive aspect about having a stable multi-language system was that when they really wanted to use a library from a third language they were comfortable just wrapping it up in a thin API and proceeding like normal. 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.

rickmb 16y ago
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.
- Retric 16y ago
  Another approach is the Windows NT rout. Where you develop a competing product to your core product and then expand it's capabilities until it replaces your core product.
  - sitmack 16y ago
    That cost MS hundreds of million dollars in development and lost opportunities. You can only do that if you have no competition. If they had added USB support to NT4 we wouldn't have needed to go to win2k. Really MS, NT4 can't support USB? They should have evolved NT4 rather than fork it into the win2k -> xp -> vista mess. They could have had the worlds best UNIX but internal dogma forced them piss in their own watering hole.

lkrubner 16y ago

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.

6ren 16y ago

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 http://www.joelonsoftware.com/articles/fog0000000069.html

metageek 16y ago

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.

Peaker 16y ago

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.