In terms of debugging, there are certainly the goofs (off-by-one, = instead of ==, and so on) which are just lapses by the programmer. The danger I think is in losing the wisdom gained in having already solved the hard problem (of course it is helpful in this regard if the original programmers are still around somewhere). It's something akin to cultural knowledge. Don't underestimate what it's going to take to rebuild it.

But perhaps we can agree, then: rewriting code is a business decision, driven by the business needs of the company. Premature rewriting is just another form of premature optimization, and can get you in trouble by putting your resources in the wrong places. But when you have a tangible threat- when you are unable to adapt to accommodate needs that you are convinced are on your horizon, then you should do it.

It should go without saying that fewer bugs is better than more bugs, though.

I'm not saying you should never rewrite a system from scratch. But I do think it's extremely costly to do so, and that it's extremely difficult to predict when you'll be driven out of business if you don't. So I don't think it's usually justifiable.

I'd be very interested if someone could supply an example of a company that was put out of business because they failed to re-write their product.

If you already saw a threat, then by the time you finish re-writing it, wouldn't you be dead?

Depends how well you can see the threat horizon.

>> What legacy code does is inhibit your ability to make the fundamental changes you need to implement in order to stay competitive.

There's always the possibility that your existing code doesn't suck, and was designed to be flexible for changes.

Ideally, you've done a good job and can rewrite small pieces of your system iteratively as needed, rather than having to chuck the whole thing.