4 ms·

> If you never have to come back to “fix it”, was it actually wrong to begin with? A dead simple and effective heuristic is to improve code a little bit each t

by dkarl 4y ago

> If you never have to come back to “fix it”, was it actually wrong to begin with? A dead simple and effective heuristic is to improve code a little bit each time you touch it. The code you touch a lot gets love and ends up nicely designed. The code you rarely touch won't be as nice, but that's fine, because you rarely touch it. If you're going to make a big functionality change or addition that will take a while, that's a great time to significantly refactor the existing code. The change will provide additional design context for the refactoring, which you wouldn't have had earlier. Of course this strategy requires you to have good tests. If you do a refactoring followed immediately by a functionality change, and you don't have good tests to verify that the refactoring is solid, you'll have trouble attributing bugs to the refactoring or the changes. If you don't have good tests and basically test in production, then you'll want to refactor ahead of time so you can deploy the refactored code and shake out the bugs before you start building on it.

chii 4y ago
> If you're going to make a big functionality change or addition that will take a while, that's a great time to significantly refactor the existing code and so here comes the trade-off question: what if such a change could be made faster/with fewer people or resources, but at the cost of not doing the refactoring?
- Nomentatus 4y ago
  It's more that you're spending a lot of time reacquainting yourself with that code; so the price of tweaking it is low. They'll be some return, even quickly from the changes; but mostly, it's the cheapest time to refactor - if you're ever gonna refactor, this is when to do it.
- dkarl 4y ago
  You have to ask what motivates the refactoring. It should speed up work in that part of the codebase, either by making the change faster or by reducing the time needed for follow-on bug fixes (which in my opinion is the same thing.) What's nice about making a refactoring right before a major change is that it's much less speculative. Your estimation of the value of a refactoring is only as good as your prediction of what changes will need to be made in the future. If you already know exactly the change you are about to make, you can justify the value of refactoring with much more confidence. By contrast, if you're worried that the change in front of you will be easy, but future changes will be hard, then maybe it will be best to leave the refactoring until just before the future changes. After all, they might not come, and if they do, they might not be what you expect. There are two reasons to do a refactoring now to account for non-immediate future work. I think only one of them is actually about the future, and the other one is really about the present. The first reason, which really is about the future, is if you do know what future changes you will have to make. For example, if you know that such-and-such future functionality will be required to support promises being made to current or prospective customers. Or if your company actually has a product roadmap that it sticks to. Then you know the refactoring will pay off eventually, and you can make a firm case for doing it now. You should discount the value of the refactoring to account for any uncertainty about the future work. The second reason is that bug fixes after the release will be easier if you do the refactoring first. I think this is the same as saying that the current change can be completed faster with the refactoring. Releasing something with a bunch of bugs doesn't make it "done." It's done when the engineers who are doing it can move on to other things. If you're stuck fixing bugs from the initial release, you aren't really done, so it wasn't done faster. Product and sales will often tell you that there are crucial strategic reasons that releasing something now with a bunch of bugs is better than releasing it a few weeks later with fewer bugs, but they're almost always lying^H^H^H^H^H suffering from tunnel vision on their own goals. Your engineering manager should escalate, and nine times out of ten the business does not actually want you to push out a piece of shit a few weeks earlier. They will tell you to descope or delay the initial release. If you count bug fixing time as part of the time spent making the upcoming change, then the refactoring becomes justified.
kqr 4y ago
> Of course this strategy requires you to have good tests. Not necessarily, if you also follow another similar principle. Leave the code a little neater than you found it, but also leave the code a little more well tested than you found it!
- solarengineer 4y ago
  Could you distinguish between "good tests" and "a little more well tested"? It seems to me that good tests enable code to be well tested. Here, "good tests" would be verification of behaviour by using the various expected and unexpected input and output.

by dkarl 4y ago

chii 4y ago

> If you're going to make a big functionality change or addition that will take a while, that's a great time to significantly refactor the existing code and so here comes the trade-off question: what if such a change could be made faster/with fewer people or resources, but at the cost of not doing the refactoring?

Nomentatus 4y ago
It's more that you're spending a lot of time reacquainting yourself with that code; so the price of tweaking it is low. They'll be some return, even quickly from the changes; but mostly, it's the cheapest time to refactor - if you're ever gonna refactor, this is when to do it.
dkarl 4y ago
You have to ask what motivates the refactoring. It should speed up work in that part of the codebase, either by making the change faster or by reducing the time needed for follow-on bug fixes (which in my opinion is the same thing.) What's nice about making a refactoring right before a major change is that it's much less speculative. Your estimation of the value of a refactoring is only as good as your prediction of what changes will need to be made in the future. If you already know exactly the change you are about to make, you can justify the value of refactoring with much more confidence. By contrast, if you're worried that the change in front of you will be easy, but future changes will be hard, then maybe it will be best to leave the refactoring until just before the future changes. After all, they might not come, and if they do, they might not be what you expect. There are two reasons to do a refactoring now to account for non-immediate future work. I think only one of them is actually about the future, and the other one is really about the present. The first reason, which really is about the future, is if you do know what future changes you will have to make. For example, if you know that such-and-such future functionality will be required to support promises being made to current or prospective customers. Or if your company actually has a product roadmap that it sticks to. Then you know the refactoring will pay off eventually, and you can make a firm case for doing it now. You should discount the value of the refactoring to account for any uncertainty about the future work. The second reason is that bug fixes after the release will be easier if you do the refactoring first. I think this is the same as saying that the current change can be completed faster with the refactoring. Releasing something with a bunch of bugs doesn't make it "done." It's done when the engineers who are doing it can move on to other things. If you're stuck fixing bugs from the initial release, you aren't really done, so it wasn't done faster. Product and sales will often tell you that there are crucial strategic reasons that releasing something now with a bunch of bugs is better than releasing it a few weeks later with fewer bugs, but they're almost always lying^H^H^H^H^H suffering from tunnel vision on their own goals. Your engineering manager should escalate, and nine times out of ten the business does not actually want you to push out a piece of shit a few weeks earlier. They will tell you to descope or delay the initial release. If you count bug fixing time as part of the time spent making the upcoming change, then the refactoring becomes justified.

kqr 4y ago

> Of course this strategy requires you to have good tests. Not necessarily, if you also follow another similar principle. Leave the code a little neater than you found it, but also leave the code a little more well tested than you found it!

solarengineer 4y ago
Could you distinguish between "good tests" and "a little more well tested"? It seems to me that good tests enable code to be well tested. Here, "good tests" would be verification of behaviour by using the various expected and unexpected input and output.