4 ms·

> But make sure you give your developers enough time to sit down with the code and understand it It means that all future developers will have to spend a lot o

> But make sure you give your developers enough time to sit down with the code and understand it It means that all future developers will have to spend a lot of time to understand complex code that could be simpler. Also, when the code is very complex, developers don't understand it fully, are hesitant and unhappy to touch it. Every new feature becomes a challenge and can break something. You need to rely on regression testing, but if you have tests, you may as well refactor. Another reason to refactor is that you want to give new developers the satisfaction of "owning" part of the code. I read an article on software engineering at Google saying that it was ok if some parts were rewritten over and over. > you can empathize with the previous devs work Some devs are just bad and/or worked under strict time constraints. Code isn't only a matter of taste. There are objective metrics that tell you if some code can be improved.

ehnto 7y ago
I'm not saying never refactor, but it's often done prematurely. > It means that all future developers will have to spend a lot of time to understand complex code that could be simpler. Code that's complex is often complex because the domain it's written for is complex. I've heard it called incidental complexity. Could you write it more simply? Potentially, but how sure are you that you're not about to get rid of edge case handling or important features? Tests only work if you're sure you understand the requirements well enough to write the test. If you're at that point of understanding in the platform, you've probably got a good idea of whether or not you should refactor. > Another reason to refactor is that you want to give new developers the satisfaction of "owning" part of the code. I read an article on software engineering at Google saying that it was ok if some parts were rewritten over and over. I think it's an attitude software learned while it's been flooded with easy money, where the tangible cost of constantly throwing away code is never really considered. Code is never considered an asset, but had you built a tractor for a company they would definitely want to know why you want to build a brand new tractor when the old one is working fine. I have mostly worked in agency environments, and as such cost is always part of the conversation. Often the only people who want the refactor is the developers. It doesn't provide any value to the business. I often do advocate for a refactor for some of the reasons you mention, but to get client buy in you need to provide some real value, and when you have to think about that it quickly discovers whether or not your refactor is frivolous.
- Bartweiss 7y ago
  > had you built a tractor for a company they would definitely want to know why you want to build a brand new tractor when the old one is working fine. You're not wrong about the cost and the need to justify it, but I think you might be underestimating how often this happens to physical products. Lists like "the worst cars of all time" are full of needless reworks, frequently driven by some executive's desire to fully "own" a product. I suspect the biggest difference is just that as the cost of throwing away a working design becomes more expensive and visible, the decision to do so slides higher up the ranks.
Bartweiss 7y ago
Truly gnarled legacy code can be almost impossible to understand just by reading, so that truly grokking it requires writing something in the codebase. (Mind, that's necessary for understanding but not sufficient.) And so at a certain point the question becomes - if you can spare the time to go beyond one-off hacks, why isn't that dev time going into adding test coverage, simplifying, etc? There are still times when knowledgeable legacy maintenance is the right answer, I think. In particular, the Catch-22 of systems built without the capacity for online updates which can't be taken down to add that capacity. I've heard horror stories of the deeply-understood hacks that keep telephone networks running, because they're ancient monoliths contracted to >99.9% uptime. But in general, the argument for not rewriting legacy code is that it takes too long, or it's going to be expired eventually, and so relying on the original author or hacking in changes is more efficient. It seems like "don't rewrite it, but repeatedly spend the time to bring new people up to full expertise" has a very narrow window where it's the right choice.
jdmichal 7y ago
> It means that all future developers will have to spend a lot of time to understand complex code that could be simpler... I've seen this story over and over. I'd argue that the following story is much, much more likely than "devs were in a hurry and wrote bad code": Developer comes in, understands the happy path, asks why there's so much code, starts advertising how they could rewrite it. Once they get the green light, they quickly implement that 80% happy path. Best-case scenario for tech, business is somehow convinced that this new thing is shiny enough that they give the go-ahead. [0] Manual workarounds are implemented for the 20% of unhappy path processes. Eventually, business will start asking for the system to automatically cover more and more of these unhappy path cases. End result: The system becomes a complex mess of code to handle these multiple edge cases. But hey, it's at least a different complex mess than before! Lesson: The code is a mess because it's encoding a messy business process full of one-offs and edge cases. Rewrites of systems like this only work if the business process is simplified in parallel with the redevelopment effort. If the business process remains unchanged, the code will reach the same endpoint. Worst-case scenario, everyone will saw-tooth oscillate every few years between "shiny, fast, and 80%" and "old, slow, and ~100%". (Worst-case because it allows for the minimum amount of ROI extracted from the technology for the same business process.) [0] This is already pretty unlikely. More likely, business is not willing to take on that work, and will demand 100% of current coverage. End result is the same, just now it happens all at once instead of sneakily over time. It's up to political and cultural inclinations whether this becomes a kill shot for the rewrite. Some places will force it through anyway, while others will see the writing on the wall and just end it.
pbalau 7y ago
> But make sure you give your developers enough time to sit down with the code and understand it > It means that all future developers will have to spend a lot of time to understand complex code that could be simpler. How did you get from one to the other? The OP's point is to give people enough time to figure things out. Not to never rewrite. We need to agree that going to either extreme, always rewrite vs never rewrite, is not a good solution, or even a solution. We should spend some energy in figuring out why to rewrite (is this code even used? is it used more than foo / time unit, is this code causing any problems as is, is it worth the time to rewrite it) and how to rewrite (make sure the new version covers all the use cases etc). In short, we should have a way to decide what to do if you say to rewrite and I say no.

ehnto 7y ago

I'm not saying never refactor, but it's often done prematurely. > It means that all future developers will have to spend a lot of time to understand complex code that could be simpler. Code that's complex is often complex because the domain it's written for is complex. I've heard it called incidental complexity. Could you write it more simply? Potentially, but how sure are you that you're not about to get rid of edge case handling or important features? Tests only work if you're sure you understand the requirements well enough to write the test. If you're at that point of understanding in the platform, you've probably got a good idea of whether or not you should refactor. > Another reason to refactor is that you want to give new developers the satisfaction of "owning" part of the code. I read an article on software engineering at Google saying that it was ok if some parts were rewritten over and over. I think it's an attitude software learned while it's been flooded with easy money, where the tangible cost of constantly throwing away code is never really considered. Code is never considered an asset, but had you built a tractor for a company they would definitely want to know why you want to build a brand new tractor when the old one is working fine. I have mostly worked in agency environments, and as such cost is always part of the conversation. Often the only people who want the refactor is the developers. It doesn't provide any value to the business. I often do advocate for a refactor for some of the reasons you mention, but to get client buy in you need to provide some real value, and when you have to think about that it quickly discovers whether or not your refactor is frivolous.

Bartweiss 7y ago
> had you built a tractor for a company they would definitely want to know why you want to build a brand new tractor when the old one is working fine. You're not wrong about the cost and the need to justify it, but I think you might be underestimating how often this happens to physical products. Lists like "the worst cars of all time" are full of needless reworks, frequently driven by some executive's desire to fully "own" a product. I suspect the biggest difference is just that as the cost of throwing away a working design becomes more expensive and visible, the decision to do so slides higher up the ranks.

Bartweiss 7y ago

Truly gnarled legacy code can be almost impossible to understand just by reading, so that truly grokking it requires writing something in the codebase. (Mind, that's necessary for understanding but not sufficient.) And so at a certain point the question becomes - if you can spare the time to go beyond one-off hacks, why isn't that dev time going into adding test coverage, simplifying, etc? There are still times when knowledgeable legacy maintenance is the right answer, I think. In particular, the Catch-22 of systems built without the capacity for online updates which can't be taken down to add that capacity. I've heard horror stories of the deeply-understood hacks that keep telephone networks running, because they're ancient monoliths contracted to >99.9% uptime. But in general, the argument for not rewriting legacy code is that it takes too long, or it's going to be expired eventually, and so relying on the original author or hacking in changes is more efficient. It seems like "don't rewrite it, but repeatedly spend the time to bring new people up to full expertise" has a very narrow window where it's the right choice.

jdmichal 7y ago

> It means that all future developers will have to spend a lot of time to understand complex code that could be simpler... I've seen this story over and over. I'd argue that the following story is much, much more likely than "devs were in a hurry and wrote bad code": Developer comes in, understands the happy path, asks why there's so much code, starts advertising how they could rewrite it. Once they get the green light, they quickly implement that 80% happy path. Best-case scenario for tech, business is somehow convinced that this new thing is shiny enough that they give the go-ahead. [0] Manual workarounds are implemented for the 20% of unhappy path processes. Eventually, business will start asking for the system to automatically cover more and more of these unhappy path cases. End result: The system becomes a complex mess of code to handle these multiple edge cases. But hey, it's at least a different complex mess than before! Lesson: The code is a mess because it's encoding a messy business process full of one-offs and edge cases. Rewrites of systems like this only work if the business process is simplified in parallel with the redevelopment effort. If the business process remains unchanged, the code will reach the same endpoint. Worst-case scenario, everyone will saw-tooth oscillate every few years between "shiny, fast, and 80%" and "old, slow, and ~100%". (Worst-case because it allows for the minimum amount of ROI extracted from the technology for the same business process.) [0] This is already pretty unlikely. More likely, business is not willing to take on that work, and will demand 100% of current coverage. End result is the same, just now it happens all at once instead of sneakily over time. It's up to political and cultural inclinations whether this becomes a kill shot for the rewrite. Some places will force it through anyway, while others will see the writing on the wall and just end it.

pbalau 7y ago

> But make sure you give your developers enough time to sit down with the code and understand it > It means that all future developers will have to spend a lot of time to understand complex code that could be simpler. How did you get from one to the other? The OP's point is to give people enough time to figure things out. Not to never rewrite. We need to agree that going to either extreme, always rewrite vs never rewrite, is not a good solution, or even a solution. We should spend some energy in figuring out why to rewrite (is this code even used? is it used more than foo / time unit, is this code causing any problems as is, is it worth the time to rewrite it) and how to rewrite (make sure the new version covers all the use cases etc). In short, we should have a way to decide what to do if you say to rewrite and I say no.