7 ms·

I was talking to a friend about "legacy code" the other day and I realised: the company that's going to put you out of business won't have any legacy code. I t

I was talking to a friend about "legacy code" the other day and I realised: the company that's going to put you out of business won't have any legacy code. I think you need to have a really good excuse not to completely rebuild your product from scratch every now and again. Because if you don't, someone else will.

jacques_chester 14y ago
> I think you need to have a really good excuse not to completely rebuild your product from scratch every now and again. And I suppose we should also burn down factories and rebuild them every now and then.
- Drakim 14y ago
  If the factories are operating with giant iron cog wheels older than your grandmother, then maybe yes, we should. The world of software is moving a lot faster than the physical world, so things can become outdated pretty quickly. Compare a 15 year old browser to a 15 year old factory.
  - cpressey 14y ago
    This attitude strikes me as wasteful. By all means, if a system has shortcomings, and you can afford to build a new system with fewer shortcomings, and migrate to it, then do that; but by itself, "it's old" is not a reason to rewrite something.
  - deleted 14y ago
    [deleted]
  - jacques_chester 14y ago
    I think that wasting money on solved problems is, essentially, bonkers. Sure, it's nice to have the latest and greatest. But I don't think it gives you magical powers. You still need to do all the other stuff. That, and the well-known problems with rewriting (the track record is notso hotso) mean that really, the onus for making a case to rewrite is on the rewriters.
  - mauvehaus 14y ago
    The difference between a browser and a factory that makes say, steel wheels for cars, is that while the web has changed dramatically in 15 years, the basic requirements for a steel wheel have not. As long as your machinery can hold the required tolerances and make product profitably and while complying with the laws that apply (like environmental), it would be foolish to scrap the old factory. If the market starts shifting to alloy wheels, and the reduced volume of sales for your steel wheels starts to affect the profitability of your factory, then maybe it makes sense to start looking at investing in updating your process to make steel wheels more cheaply at lower volume or to dump steel wheels entirely and start manufacturing alloys. The Air Force Heavy Press Program made the rounds on the internet last year when Alcoa refurbished its 50,000 ton forging press in Cleveland [1]. It's been around since 1955, and it's almost unique in its capabilities within the USA. The idea that it should be replaced simply because it's old is, frankly, insane. That's obviously a pretty extreme example, but the fundamental requirements for a metal lathe or end mill haven't changed in years. Yes, there are multi-axis CNC machines that can do vastly more operations before somebody has to change the setup on them than on a basic lathe or mill. If you aren't making something that requires a lot of steps, the basic lathe or mill might still viable. Just because the rate of change in requirements over time is huge in software doesn't mean that it's true everywhere. If an old factory can continue to meet the requirements, it's probably hard to justify changing it just to be up to date. EDIT: Forgot the link [1] http://www.theatlantic.com/magazine/archive/2012/03/iron-giant/308886/ http://www.theatlantic.com/magazine/archive/2012/03/iron-gia... [1]
bryanlarsen 14y ago
OTOH, the greatest asset you have competing against the company that's going to put you out of business is your legacy code. Every line in your legacy code is there for a reason. Sometimes the reasons are bad, but often they're there because of some very valuable lesson you learned from a customer, a mistake you made that your competitor is also likely to eventually make. Throwing away your legacy code means that it's likely you'll make the same mistake again.
- cpressey 14y ago
  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.
  - dhimes 14y ago
    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.
    - tomelders 14y ago
      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.
peteretep 14y ago
> the company that's going to put you out of business won't have any legacy code Code becomes legacy pretty quickly, in my experience... Architectural decisions that were obvious before you had real customers rarely stand up to real usage. The company that's "going to put you out of business" also doesn't currently have any working or revenue-generating code, and are unlikely to immediately understand the architectural challenges... > I think you need to have a really good excuse not to completely rebuild your product from scratch every now and again It pretty much just doesn't work in the real world; how's that for an excuse? As other people have said, you need to scaffold interfaces, and rebuild small parts. Any company that isn't continually reinvesting in making their codebase better will accumulate technical debt pretty fast; but the throw it away and start from scratch approach rarely works on big systems.
- tomelders 14y ago
  Maybe, maybe not. I've never been presented with any evidence that supports that view. I'm not saying you're wrong, I'm just saying I've got no reason to believe you're right. And vice versa.
  - jodrellblank 14y ago
    http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html It is just someone else saying the same thing, or it's a real world example, or it's anecdotes-aren't-data.
jackalope 14y ago
I think I'd rephrase that to: The company that's going to put you out of business is using an early version of their own legacy code. It's not always obvious when you should attempt a rewrite from scratch. Having done a few refactorings, I've noticed one desirable trait in good code bases: If you can implement new logic easily in a few lines of code, it's probably a good design. But if you need to get out the surgeon's knife and write tons of new code every time you want to implement new logic, it might be fundamentally flawed enough to warrant a complete rewrite. A good design is adaptable and will allow you to be resilient against newcomers.
sultezdukes 14y ago
I consider "legacy" code any code that has been committed and is dependent upon. I look at code that is 3 weeks old (has had a few additional commits), and start cringing. All code gets ugly fast. At the end of the day you have to pick your battles wisely.
abbyroad9191 14y ago
If it ain't broke don't fix it. If you've got a team of about 10 - 15 engineers that'd be over a million dollars you'd be burning in 1 year for a code rewrite. And most code rewrites that I've seen or been a part of take more than 1 year.
- greenyoda 14y ago
  I'd agree with the "more than 1 year" estimate for any large code base. It could even be several years if your run into unforeseen problems. You probably don't want to even start a rewrite like that without first spending a few months thinking really hard about the architecture of the new system and making sure you'll end up with a feature set that does everything that your customers depended on in the old code. And furthermore, while the developers are rewriting the code, who is going to maintain the old code? The demands for new features and bug fixes aren't going to stop just because you've decided to rewrite the code.
bijupunalor 14y ago
"Netscape wasn't the first company to make this mistake. Borland made the same mistake when they bought Arago and tried to make it into dBase for Windows, a doomed project that took so long that Microsoft Access ate their lunch, then they made it again in rewriting Quattro Pro from scratch and astonishing people with how few features it had. Microsoft almost made the same mistake, trying to rewrite Word for Windows from scratch in a doomed project called Pyramid which was shut down, thrown away, and swept under the rug" "Things You Should Never Do" http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html
- yuhong 14y ago
  Not exactly the same mistake but this is even worse: http://yuhongbao.blogspot.ca/2012/12/about-ms-os2-20-fiasco-px00307-and-dr.html http://yuhongbao.blogspot.ca/2012/12/about-ms-os2-20-fiasco-...
coldtea 14y ago
Netscape was put out of business for doing just that: rebuilding Mozilla/Geeko from scratch and missing lots of time while MS grabbed market share. Sure, we know have Firefox, but that's little consolation for the corporate entity that was Netscape.
Surio 14y ago
oldie but goldie: http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html
nathan_long 14y ago
>> the company that's going to put you out of business won't have any legacy code. Even assuming their newly-minted code is better (which others have disputed), what they don't have is loyal customers and brand recognition. If you're worth competing with, you do. >> I think you need to have a really good excuse not to completely rebuild your product from scratch every now and again. There could be many reasons. 1) That's expensive. 2) May introduce new bugs. 3) Interface changes may alienate existing customers. 4) Switching technologies may require new developers. I wouldn't say "plan to rebuild from scratch periodically." I'd say "design your software to be flexible, watch your competitors, and iterate to ensure they don't leave you in the dust." If it becomes clear that you can't compete on features without a rewrite, then consider it.

jacques_chester 14y ago

> I think you need to have a really good excuse not to completely rebuild your product from scratch every now and again. And I suppose we should also burn down factories and rebuild them every now and then.

Drakim 14y ago
If the factories are operating with giant iron cog wheels older than your grandmother, then maybe yes, we should. The world of software is moving a lot faster than the physical world, so things can become outdated pretty quickly. Compare a 15 year old browser to a 15 year old factory.
- cpressey 14y ago
  This attitude strikes me as wasteful. By all means, if a system has shortcomings, and you can afford to build a new system with fewer shortcomings, and migrate to it, then do that; but by itself, "it's old" is not a reason to rewrite something.
- deleted 14y ago
  [deleted]
- jacques_chester 14y ago
  I think that wasting money on solved problems is, essentially, bonkers. Sure, it's nice to have the latest and greatest. But I don't think it gives you magical powers. You still need to do all the other stuff. That, and the well-known problems with rewriting (the track record is notso hotso) mean that really, the onus for making a case to rewrite is on the rewriters.
- mauvehaus 14y ago
  The difference between a browser and a factory that makes say, steel wheels for cars, is that while the web has changed dramatically in 15 years, the basic requirements for a steel wheel have not. As long as your machinery can hold the required tolerances and make product profitably and while complying with the laws that apply (like environmental), it would be foolish to scrap the old factory. If the market starts shifting to alloy wheels, and the reduced volume of sales for your steel wheels starts to affect the profitability of your factory, then maybe it makes sense to start looking at investing in updating your process to make steel wheels more cheaply at lower volume or to dump steel wheels entirely and start manufacturing alloys. The Air Force Heavy Press Program made the rounds on the internet last year when Alcoa refurbished its 50,000 ton forging press in Cleveland [1]. It's been around since 1955, and it's almost unique in its capabilities within the USA. The idea that it should be replaced simply because it's old is, frankly, insane. That's obviously a pretty extreme example, but the fundamental requirements for a metal lathe or end mill haven't changed in years. Yes, there are multi-axis CNC machines that can do vastly more operations before somebody has to change the setup on them than on a basic lathe or mill. If you aren't making something that requires a lot of steps, the basic lathe or mill might still viable. Just because the rate of change in requirements over time is huge in software doesn't mean that it's true everywhere. If an old factory can continue to meet the requirements, it's probably hard to justify changing it just to be up to date. EDIT: Forgot the link [1] http://www.theatlantic.com/magazine/archive/2012/03/iron-giant/308886/ http://www.theatlantic.com/magazine/archive/2012/03/iron-gia... [1]

bryanlarsen 14y ago

OTOH, the greatest asset you have competing against the company that's going to put you out of business is your legacy code. Every line in your legacy code is there for a reason. Sometimes the reasons are bad, but often they're there because of some very valuable lesson you learned from a customer, a mistake you made that your competitor is also likely to eventually make. Throwing away your legacy code means that it's likely you'll make the same mistake again.

cpressey 14y ago
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.
- dhimes 14y ago
  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.
  - tomelders 14y ago
    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.

peteretep 14y ago

> the company that's going to put you out of business won't have any legacy code Code becomes legacy pretty quickly, in my experience... Architectural decisions that were obvious before you had real customers rarely stand up to real usage. The company that's "going to put you out of business" also doesn't currently have any working or revenue-generating code, and are unlikely to immediately understand the architectural challenges... > I think you need to have a really good excuse not to completely rebuild your product from scratch every now and again It pretty much just doesn't work in the real world; how's that for an excuse? As other people have said, you need to scaffold interfaces, and rebuild small parts. Any company that isn't continually reinvesting in making their codebase better will accumulate technical debt pretty fast; but the throw it away and start from scratch approach rarely works on big systems.

tomelders 14y ago
Maybe, maybe not. I've never been presented with any evidence that supports that view. I'm not saying you're wrong, I'm just saying I've got no reason to believe you're right. And vice versa.
- jodrellblank 14y ago
  http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html It is just someone else saying the same thing, or it's a real world example, or it's anecdotes-aren't-data.

jackalope 14y ago

I think I'd rephrase that to: The company that's going to put you out of business is using an early version of their own legacy code. It's not always obvious when you should attempt a rewrite from scratch. Having done a few refactorings, I've noticed one desirable trait in good code bases: If you can implement new logic easily in a few lines of code, it's probably a good design. But if you need to get out the surgeon's knife and write tons of new code every time you want to implement new logic, it might be fundamentally flawed enough to warrant a complete rewrite. A good design is adaptable and will allow you to be resilient against newcomers.

sultezdukes 14y ago

I consider "legacy" code any code that has been committed and is dependent upon. I look at code that is 3 weeks old (has had a few additional commits), and start cringing. All code gets ugly fast. At the end of the day you have to pick your battles wisely.

abbyroad9191 14y ago

If it ain't broke don't fix it. If you've got a team of about 10 - 15 engineers that'd be over a million dollars you'd be burning in 1 year for a code rewrite. And most code rewrites that I've seen or been a part of take more than 1 year.

greenyoda 14y ago
I'd agree with the "more than 1 year" estimate for any large code base. It could even be several years if your run into unforeseen problems. You probably don't want to even start a rewrite like that without first spending a few months thinking really hard about the architecture of the new system and making sure you'll end up with a feature set that does everything that your customers depended on in the old code. And furthermore, while the developers are rewriting the code, who is going to maintain the old code? The demands for new features and bug fixes aren't going to stop just because you've decided to rewrite the code.

bijupunalor 14y ago

"Netscape wasn't the first company to make this mistake. Borland made the same mistake when they bought Arago and tried to make it into dBase for Windows, a doomed project that took so long that Microsoft Access ate their lunch, then they made it again in rewriting Quattro Pro from scratch and astonishing people with how few features it had. Microsoft almost made the same mistake, trying to rewrite Word for Windows from scratch in a doomed project called Pyramid which was shut down, thrown away, and swept under the rug" "Things You Should Never Do" http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html

yuhong 14y ago
Not exactly the same mistake but this is even worse: http://yuhongbao.blogspot.ca/2012/12/about-ms-os2-20-fiasco-px00307-and-dr.html http://yuhongbao.blogspot.ca/2012/12/about-ms-os2-20-fiasco-...

coldtea 14y ago

Netscape was put out of business for doing just that: rebuilding Mozilla/Geeko from scratch and missing lots of time while MS grabbed market share. Sure, we know have Firefox, but that's little consolation for the corporate entity that was Netscape.

Surio 14y ago

oldie but goldie: http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html

nathan_long 14y ago

>> the company that's going to put you out of business won't have any legacy code. Even assuming their newly-minted code is better (which others have disputed), what they don't have is loyal customers and brand recognition. If you're worth competing with, you do. >> I think you need to have a really good excuse not to completely rebuild your product from scratch every now and again. There could be many reasons. 1) That's expensive. 2) May introduce new bugs. 3) Interface changes may alienate existing customers. 4) Switching technologies may require new developers. I wouldn't say "plan to rebuild from scratch periodically." I'd say "design your software to be flexible, watch your competitors, and iterate to ensure they don't leave you in the dust." If it becomes clear that you can't compete on features without a rewrite, then consider it.