Legacy code will also tend to have had many of its bugs ironed out, since it's been in operation for so long. New code will have a whole new set of coding errors hidden in it, and you'll have to go through that ironing-out all over again.

I think this is a crucial point we all overlook in our rush to throw out the legacy code and 'do it right this time.' We're thinking, 'but we'll have unit tests so we'll catch the bugs.' But in reality, some get through and they tend to be a real pain in the ass.

I know this probably means that I don't unit test right. It also obviously means I don't code right, because I have bugs. The point is, these are facts of (real) life, and to be successful you have to manage the reality. Often this means that the best course of action is to stick with the legacy code.

You'll have bugs either way. That's a fact of life, and the vast majority of a developers time will always be spent debugging.

What legacy code does is inhibit your ability to make the fundamental changes you need to implement in order to stay competitive. And I'm not saying throw you code out every other week. And I'm not saying every attempt to rewrite your product should replace what you already have. But the for all the costs associated with re-writing your product, they pale into insignificance when compared to being put out of business.

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.

Exactly.

Also, code that might look crap and seem to do weird stuff often handles intricate edge cases. But due to the lack of comments, it's not obvious what's going on.

I've been involved in several component refactorings when as a team we've gone "look how complicated the old code is, we can make it much simpler".

When we've re-written it and then tested it with actual production use cases, it then becomes obvious why the code was so convoluted previously. So time was wasted, but at least there are comments now (and in those cases, the code's slightly better).

It seems there's an assumption here that building your product again means throwing out all of your experience. What I thought would have been self evident is that by starting again, you bring to the table all your experience and you harness that to build a better product.

Because that's exactly what someone else is going to do. The company that makes the product that competes with yours is unlikely to have picked your product at random and simply decided to compete against it on a whim. There's a good chance they've been using your product and have become so frustrated with it's shortcomings that they've had a crack a building there own version. They've been on your support forums that detail every bug and bad descision, they've read the blog post detailing exactly what is wrong with your features and how they could be done better. They've stared at their screen in a full on rage wondering why the hell your product doesn't do things in a way that makes sense. They have their own experience and they are not afraid to use it.

There could be one, tens or hundreds of people who decide to do this. Many will fail, but if one succeeds then you have a serious problem. The continued success of your product can no longer rely on it's features unless you're prepared to make some fundamental changes. Only now you have a deadline, whereas before you could have worked at your own pace.

You're right when you say your legacy code is your greatest asset. It's proof of what is a good idea and what is a bad idea. But that doesn't mean you should keep it around any longer than you have to.

"It seems there's an assumption here that building your product again means throwing out all of your experience. What I thought would have been self evident is that by starting again, you bring to the table all your experience and you harness that to build a better product"

Ideally, yes! Realistically, there's always some hairy, gnarly wisdom "baked into" the code.

The definitive article is Joel Sposky's article on the perils of writing from scratch. If you only want to read a few paragraphs:

"Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work."

http://www.joelonsoftware.com/articles/fog0000000069.html

Ideally, yeah, you take that wisdom with you to the new project but realistically (even if you've followed great documentation practices, etc, for all of those hairy kludges) the rewrite-from-scratch is never as easy as one thinks.