3 ms·

I think we can all agree that the dev who starts a big refactor and then drops it when it's half-done is a terrible human being

bradstewart 6y ago
I don't agree. Big refactors are _hard_. They usually require levels of sustained focus at multiple layers of abstraction, and its really easy to get exhausted/burnt out or be forced to switch gears in the middle. People learn by doing. And after a few such messes, the dev will learn how to do smaller refactors.
droobles 6y ago
That's me. I want to finish my refactor but business requirements have me pumping out new epics. I chip away at it in my down time but it's no longer prioritized. I find in this line of work, you will always seek to find ways to balance business/market needs vs. being a paragon of programming.
mcv 6y ago
There's not always time to finish it properly, but there's often a good stopping point halfway. When there's a lot that needs refactoring, I start with one specific thing, and leave the rest for now, so the piece I've bitten off is still small enough that it can be wrapped up in a reasonable amount of time. And the rest will have to wait. In my current project, there are piece of code that I've wanted to remove for months now. I was working on refactoring it out completely, but there's one place that still uses it, and that wasn't so easy to fix as all the other places where it had become unnecessary. It still needs to be done, but there hasn't been any time. Or urgency, really. But it's still there, taking up space in my head.
- flavious 6y ago
  And how does the team feel about it?
  - mcv 6y ago
    They also want to get rid of the old code, but they're not removing it. One of them also has a tendency to interesting structural solutions, though he tends to do it more by adding them than by rewriting what was already there, which has the advantage that it doesn't disrupt the old code that others are working on, and the corresponding disadvantage that the old code survives.

bradstewart 6y ago

I don't agree. Big refactors are _hard_. They usually require levels of sustained focus at multiple layers of abstraction, and its really easy to get exhausted/burnt out or be forced to switch gears in the middle. People learn by doing. And after a few such messes, the dev will learn how to do smaller refactors.

droobles 6y ago

That's me. I want to finish my refactor but business requirements have me pumping out new epics. I chip away at it in my down time but it's no longer prioritized. I find in this line of work, you will always seek to find ways to balance business/market needs vs. being a paragon of programming.

mcv 6y ago

There's not always time to finish it properly, but there's often a good stopping point halfway. When there's a lot that needs refactoring, I start with one specific thing, and leave the rest for now, so the piece I've bitten off is still small enough that it can be wrapped up in a reasonable amount of time. And the rest will have to wait. In my current project, there are piece of code that I've wanted to remove for months now. I was working on refactoring it out completely, but there's one place that still uses it, and that wasn't so easy to fix as all the other places where it had become unnecessary. It still needs to be done, but there hasn't been any time. Or urgency, really. But it's still there, taking up space in my head.

flavious 6y ago
And how does the team feel about it?
- mcv 6y ago
  They also want to get rid of the old code, but they're not removing it. One of them also has a tendency to interesting structural solutions, though he tends to do it more by adding them than by rewriting what was already there, which has the advantage that it doesn't disrupt the old code that others are working on, and the corresponding disadvantage that the old code survives.