5 ms·

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

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.

cpressey 14y ago
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.
- Tyr42 14y ago
  If you already saw a threat, then by the time you finish re-writing it, wouldn't you be dead?
  - dhimes 14y ago
    Depends how well you can see the threat horizon.
dhimes 14y ago
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.
nathan_long 14y ago
>> 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.

cpressey 14y ago

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.

Tyr42 14y ago
If you already saw a threat, then by the time you finish re-writing it, wouldn't you be dead?
- dhimes 14y ago
  Depends how well you can see the threat horizon.

dhimes 14y ago

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.

nathan_long 14y ago

>> 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.