8 ms·

This is the most overrated and overquoted piece of (bad) software engineering advice ever. Sure, it's harder to read unfamiliar code than write new code, becaus

by romaniv 13y ago

This is the most overrated and overquoted piece of (bad) software engineering advice ever. Sure, it's harder to read unfamiliar code than write new code, because your understand the reasoning behind the new code. That's exactly why rewrites often make much more sense than labor-intensive incremental changes. I've had many real-life situations where I successfully chain-deleted thousands of lines of legacy code and replaced it with some sub-100-line method that simply worked. All that without understanding how legacy code works. You're wondering what's the secret here? Instead of trying to deduce the undocumented logic behind legacy code I gathered current requirements and implemented them in the simplest way possible. In most cases the results were dramatically more readable, because I used build-in language capabilities and standard libraries whereas old code spectacularly failed to do so. Also, I didn't have to worry about requirements that were no longer relevant.

jbert 13y ago
> I gathered current requirements and implemented them in the simplest way possible. If you can get complete current requirements, that's fine. The issue with this is "all the stuff which falls through the cracks". In the example from the post, some code to "handle case where internet explorer is not installed". That the sort of thing which would often be missed in requirements gathering, discovered in the field and then patched into the codebase. Sure - if you have one of: * close-enought-to-perfect requirements * close-enought-to-perfect regression tests then a rewrite isn't too hard. But achieving either of the above is something I'd consider a hard problem. Do you have a particular way of getting signoff that your current requirements are "complete"? That would be worth knowing :-)
- kyllo 13y ago
  Yeah, my favorite definition of "legacy code" is "code that has poor test coverage." The regression test suite should literally implement all of the business requirements, and then the two become the same thing (if there's no test for it, it's not a requirement, and vice versa), so then you can work on the codebase with confidence, and it's therefore not legacy code, no matter how old it is or what old school language it's written in.
enraged_camel 13y ago
>>I've had many real-life situations where I successfully chain-deleted thousands of lines of legacy code and replaced it with some sub-100-line method that simply worked. All that without understanding how legacy code works. You're wondering what's the secret here? Instead of trying to deduce the undocumented logic behind legacy code I gathered current requirements and implemented them in the simplest way possible. Except one of the main reasons legacy code tends to be so long is that it deals with tens/hundreds of small edge-cases or bugs that your "sub-100-line method" simply cannot account for. So what you are doing when you re-write the legacy code without even understanding what it does is regressing the product by several years in terms of maturity and stability. Your new code will face the same problems the legacy code did, except it will break. And then you will have to start adding to it... Now, it is absolutely possible that those edge-cases and bugs that the legacy code dealt with are no longer an issue: maybe they were added back in Windows XP days, and your users no longer use Windows XP, or something. In that case, yes, go ahead and rewrite it. But you need to think about and understand what it does first, and why.
- barking 13y ago
  Exactly, It comes across as really arrogant to replace thousands of lines like that without even looking at them. Maybe those old timers first iteration only had 100 lines too.
  - nairteashop 13y ago
    I've done massive refactorings in the past as the parent is suggesting. But before I do it, I try to figure out whether the code is hard to read because the developer was bad, or because a good developer was forced to add support for hundreds of edge cases over the years. If I notice at a cursory glance that I can replace more than a few ridiculously convoluted chunks of code with something simpler and be sure that I broke no edge case for those chunks, I just assume that the previous developer was simply incompetent and rewrite the whole thing to meet the original requirements. (And perhaps down the line a developer better than I will do the same with my code!)
  - coolsunglasses 13y ago
vectorpush 13y ago
I've had many real-life situations where I successfully chain-deleted thousands of lines of legacy code and replaced it with some sub-100-line method that simply worked. This just about never happens outside of start-up world. You can't go around deleting thousands of lines that you don't understand and just pray that your new implementation won't silently (or catastrophically) break subtle side-effects (errors or otherwise) that the organization has adapted its business around. That's just madness and would probably get you fired in most places.
- ebiester 13y ago
  Eh, We just did the equivalent in an enterprise app. It's amazing how convoluted code can get when someone doesn't sit back and think. It's true -- if a codebase is predominantly written and maintained by competent developers who write good tests and are given the authority to refactor as they go, this shouldn't happen. On the other hand, who wrote it can be a significant factor in the decision.
deleted 13y ago
[deleted]
rblatz 13y ago
I hate working with people that have this attitude. Blowing away old code that works and rewriting it, because obviously they are the smartest person, and can do it better than anyone else. I've had no end of regressions and just full out failures because someone rewrites code and doesn't understand what it does or why it does it. Then I come in and see that if they had only spent an hour reviewing the code and understanding it, we would have saved weeks of development and testing time.
avenger123 13y ago
I would be hesitant to just make a broad statement like 'overquoted pice of (bad) software engineering advice ever' just based on your experience. It's one thing to replace legacy plumbing code (which what you describe is likely just that) with new 5 line plumbing code. It's quite another to walk through lines and lines of classic ASP code (sub your own 'legacy' language here) that mixes data access with business logic and perfectly meets the businesses needs. I have found it hard to go to a client and say we will build you a new version of the application but most of the cost is in the rewrite to make the software more "modern" and only a small portion of the cost is new features. Also, try getting current requirements from business stakeholders who sometimes don't even have a clue what the behind the scene 'magic' is happening in the application but it fits their business needs and gathering requirements amounts to 'do what the app already does'. I certainly don't disagree with your opinion but I would venture that if Joel's advice were to be treated as a software development pattern, it would generally fit the situation.

by romaniv 13y ago

jbert 13y ago

> I gathered current requirements and implemented them in the simplest way possible. If you can get complete current requirements, that's fine. The issue with this is "all the stuff which falls through the cracks". In the example from the post, some code to "handle case where internet explorer is not installed". That the sort of thing which would often be missed in requirements gathering, discovered in the field and then patched into the codebase. Sure - if you have one of: * close-enought-to-perfect requirements * close-enought-to-perfect regression tests then a rewrite isn't too hard. But achieving either of the above is something I'd consider a hard problem. Do you have a particular way of getting signoff that your current requirements are "complete"? That would be worth knowing :-)

kyllo 13y ago
Yeah, my favorite definition of "legacy code" is "code that has poor test coverage." The regression test suite should literally implement all of the business requirements, and then the two become the same thing (if there's no test for it, it's not a requirement, and vice versa), so then you can work on the codebase with confidence, and it's therefore not legacy code, no matter how old it is or what old school language it's written in.

enraged_camel 13y ago

>>I've had many real-life situations where I successfully chain-deleted thousands of lines of legacy code and replaced it with some sub-100-line method that simply worked. All that without understanding how legacy code works. You're wondering what's the secret here? Instead of trying to deduce the undocumented logic behind legacy code I gathered current requirements and implemented them in the simplest way possible. Except one of the main reasons legacy code tends to be so long is that it deals with tens/hundreds of small edge-cases or bugs that your "sub-100-line method" simply cannot account for. So what you are doing when you re-write the legacy code without even understanding what it does is regressing the product by several years in terms of maturity and stability. Your new code will face the same problems the legacy code did, except it will break. And then you will have to start adding to it... Now, it is absolutely possible that those edge-cases and bugs that the legacy code dealt with are no longer an issue: maybe they were added back in Windows XP days, and your users no longer use Windows XP, or something. In that case, yes, go ahead and rewrite it. But you need to think about and understand what it does first, and why.

barking 13y ago
Exactly, It comes across as really arrogant to replace thousands of lines like that without even looking at them. Maybe those old timers first iteration only had 100 lines too.
- nairteashop 13y ago
  I've done massive refactorings in the past as the parent is suggesting. But before I do it, I try to figure out whether the code is hard to read because the developer was bad, or because a good developer was forced to add support for hundreds of edge cases over the years. If I notice at a cursory glance that I can replace more than a few ridiculously convoluted chunks of code with something simpler and be sure that I broke no edge case for those chunks, I just assume that the previous developer was simply incompetent and rewrite the whole thing to meet the original requirements. (And perhaps down the line a developer better than I will do the same with my code!)
- coolsunglasses 13y ago

vectorpush 13y ago

I've had many real-life situations where I successfully chain-deleted thousands of lines of legacy code and replaced it with some sub-100-line method that simply worked. This just about never happens outside of start-up world. You can't go around deleting thousands of lines that you don't understand and just pray that your new implementation won't silently (or catastrophically) break subtle side-effects (errors or otherwise) that the organization has adapted its business around. That's just madness and would probably get you fired in most places.

ebiester 13y ago
Eh, We just did the equivalent in an enterprise app. It's amazing how convoluted code can get when someone doesn't sit back and think. It's true -- if a codebase is predominantly written and maintained by competent developers who write good tests and are given the authority to refactor as they go, this shouldn't happen. On the other hand, who wrote it can be a significant factor in the decision.

deleted 13y ago

[deleted]

rblatz 13y ago

I hate working with people that have this attitude. Blowing away old code that works and rewriting it, because obviously they are the smartest person, and can do it better than anyone else. I've had no end of regressions and just full out failures because someone rewrites code and doesn't understand what it does or why it does it. Then I come in and see that if they had only spent an hour reviewing the code and understanding it, we would have saved weeks of development and testing time.

avenger123 13y ago

I would be hesitant to just make a broad statement like 'overquoted pice of (bad) software engineering advice ever' just based on your experience. It's one thing to replace legacy plumbing code (which what you describe is likely just that) with new 5 line plumbing code. It's quite another to walk through lines and lines of classic ASP code (sub your own 'legacy' language here) that mixes data access with business logic and perfectly meets the businesses needs. I have found it hard to go to a client and say we will build you a new version of the application but most of the cost is in the rewrite to make the software more "modern" and only a small portion of the cost is new features. Also, try getting current requirements from business stakeholders who sometimes don't even have a clue what the behind the scene 'magic' is happening in the application but it fits their business needs and gathering requirements amounts to 'do what the app already does'. I certainly don't disagree with your opinion but I would venture that if Joel's advice were to be treated as a software development pattern, it would generally fit the situation.