3 ms·

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 ha

by 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
Well, maybe. It really depends and you won't know unless you're reading the code and cross-referencing with applicable unit/regression tests. Some of my most productive days have been in eliminating unnecessary/poorly written code, not in adding lines. But you can't do that unless you know: 1. What the program should do 2. What the specific code you're looking at is trying to accomplish vs. what it actually does Bringing #2 (what it actually does) into synchronization with what it's supposed to do can allow you to eliminate code, and the opportunities for reducing the overall amount of code grows as you look at a wider scope/% of the overall project. But it all depends.
romaniv 13y ago
I didn't say I never looked at them. I said I didn't need to understand how they worked. There is a huge difference. For example, I've seen logic that looked at roughly 10 user input fields and generated one out of 30 pre-defined values. That was the extent of what it did. It had multiple classes, complex global state management, database and session interactions and thousands lines of code (with no automated tests or comments). That's how real legacy code looks. When asked to modify something like that, a bad developer would simply add a few more lines of code, do some manual testing and move on. Another kind of bad developer would start refactoring that code 'by the book', writing unit tests... and would never finish. A good developer would start by asking what is the point of that final value the code generates and why we really want to modify the logic. Sure, you want another classification of stuff, but why? In my case I realized that everything and everyone that were relying on that final value could use something else. Instead of spending time messing around with pathological code from above I spent my time switching systems and people to using other values. Then I simply removed that legacy classification mess altogether. The number of tickets we got for the system dropped by at least 50%. I still don't know exactly how all that code worked, because I merely traced out where it interacted with the rest of the world. Someone will surely comment "But that's refactoring!". I don't care how you call it, because at the time and place I was working on the project it was considered a rewrite, and that's what matters. If everyone followed Joel's advice, no one would question the necessity of that code, no one would look at deleting it altogether it would still be there, except bigger and buggier.

by 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

Well, maybe. It really depends and you won't know unless you're reading the code and cross-referencing with applicable unit/regression tests. Some of my most productive days have been in eliminating unnecessary/poorly written code, not in adding lines. But you can't do that unless you know: 1. What the program should do 2. What the specific code you're looking at is trying to accomplish vs. what it actually does Bringing #2 (what it actually does) into synchronization with what it's supposed to do can allow you to eliminate code, and the opportunities for reducing the overall amount of code grows as you look at a wider scope/% of the overall project. But it all depends.

romaniv 13y ago

I didn't say I never looked at them. I said I didn't need to understand how they worked. There is a huge difference. For example, I've seen logic that looked at roughly 10 user input fields and generated one out of 30 pre-defined values. That was the extent of what it did. It had multiple classes, complex global state management, database and session interactions and thousands lines of code (with no automated tests or comments). That's how real legacy code looks. When asked to modify something like that, a bad developer would simply add a few more lines of code, do some manual testing and move on. Another kind of bad developer would start refactoring that code 'by the book', writing unit tests... and would never finish. A good developer would start by asking what is the point of that final value the code generates and why we really want to modify the logic. Sure, you want another classification of stuff, but why? In my case I realized that everything and everyone that were relying on that final value could use something else. Instead of spending time messing around with pathological code from above I spent my time switching systems and people to using other values. Then I simply removed that legacy classification mess altogether. The number of tickets we got for the system dropped by at least 50%. I still don't know exactly how all that code worked, because I merely traced out where it interacted with the rest of the world. Someone will surely comment "But that's refactoring!". I don't care how you call it, because at the time and place I was working on the project it was considered a rewrite, and that's what matters. If everyone followed Joel's advice, no one would question the necessity of that code, no one would look at deleting it altogether it would still be there, except bigger and buggier.