Thanks to Mike Swaine at Dr Dobbs' Journal, I found this site (see DDJ Oct 2001 Programming Paradigms).

The discovery came one day after sending the following to a team of about 150 techos, some of whom are in the "hate MS, just because" camp and parading the recent postulations and prognostications of the Gartner Group:

'...Anyone listening to Gartner for technical advice might be better off in a hairdressing salon...'

And my followup, after reading through the site, and especially the "Things You Should Never Do, Part I" with the spooky picture of a barber shop:

'A lucid thought on the sagacity of Gartner commenting on items of technical import...

http://www.joelonsoftware.com/2001/09/24

added to that is his picture, which shows this guy doesn't hang around in hairdressing salons either.'

Thanks, Joel. You are a real man.

-- Anonymous, September 26, 2001

Answers

I don't know. I think sometimes Joel is off base. A religious devotion to the concept "never, ever, ever, ever do a re-write" seems absurd in light of IIS.

Sometimes refactoring a pile of shit is a more bug-prone process than starting over.

I'd recommend Microsoft starting over with IIS.

-- Anonymous, September 28, 2001

I agree with you, Tom. I believe there are times when a rewrite is called for. And at the same time, Joel makes some good points.

Here are the arguments I saw Joel make against rewrites in his essay, in a nutshell:

• The old code has been used and tested. New code hasn't.
• The old code has many bug fixes that may return in the rewrite.
• Rewriting requires large sums of money to repeat the functionality of the old code.
• A company doing a rewrite will appear to the outside world to be making no progress. (Sort of like when your OS suddenly does a disk defrag operation, except that you can't hear the company's hard drive whirring furiously.)
• Anything you were planning on fixing with a rewrite can be fixed by refactoring instead.

  That fifth argument is the clincher for me. I've come upon countless examples of code that needed parts of itself replaced in order to make further progress on the code. The worst examples I'd seen would've required replacing ALL of the code. But even in those cases, one could probably have done it piece by piece, while testing thoroughly and still adding features and making other improvements that are visible to customers.

  Given this, I'd say rewrites are called for only those rare cases when none of the above arguments holds. The old code would have to have been mothballed for a long time, years say, or its userbase is practically nil. It has to have been bug-ridden even in its heyday. Rewriting is coupled with redesign with other improvements, even as small as updating the program to work with current hardware. The company may have multiple products, which pick up the slack for the rewritten one. And an argument would have to be made that the entire mass of code would be refactored. Does IIS fit these traits?

  The one big problem I can see is when a company is so hellbent on making improvements that the refactoring effort can't keep up. The code becomes cruftier and cruftier, each new feature requiring more and more money to add. Such companies may make the mistake of siphoning resources from the refactoring and testing efforts to feed the feature-adding effort, and could very well suffocate themselves.
  
  -- Anonymous, September 28, 2001