3 ms·

another reason to not refactor is management will start out supportive of it but some weeks in they will wonder wtf their engineers are doing all day and why ar

another reason to not refactor is management will start out supportive of it but some weeks in they will wonder wtf their engineers are doing all day and why aren't they building the new pile of stuff they want built yesterday.

eyelidlessness 2y ago
That’s not so much a reason, in my experience, as a frequent default/inertia position. In other words, I expect to start at that default, and challenge it with reasoning, in order to justify a significant refactor.
svachalek 2y ago
Refactoring is a terrible project plan. You never want your weekly status to be "refactored some more". Plan your other development work with enough time to refactor as you go.
lesuorac 2y ago
The ability to ship small things is I think something really missed in discussion about microservices. Like rather then refactoring the entire application to support a faster cache or something you can just add in another microservice that handles caching of the data. If some way you write the services is poor you can rewrite one of the services a new way and easily evaluate if it's actually a good idea to change the rest or not.
IshKebab 2y ago
Don't spend 100% of your time refactoring.
zingar 2y ago
I do encounter hostility but what I've realised is that it comes from experience of refactoring being done badly. "We made time for this refactoring thing but it made no difference so now we're not going to 'refactor' anymore". The worst hostility is often from management that used to be technical but never learned how to refactor effectively so they have what they think is justifiable scepticism. s/refactoring/pairing or any other technique that is good in theory but requires skill to implement. I usually find that people without technical background are willing to follow the advice of the developers that work with them, taking the things that work with them into their next roles. If refactoring worked in the beginning they'll be open to it in future, if it didn't work they'll dismiss it. Edit: also - what everyone else said - "refactoring" isn't a business goal, it's one part of achieving the goal. Achieve the goal and no-one cares how you did it. ("add a new button to that widget" isn't a business goal either so there is a tricky aspect of getting management to understand that they should be bringing you problems/goals not solutions)

eyelidlessness 2y ago

That’s not so much a reason, in my experience, as a frequent default/inertia position. In other words, I expect to start at that default, and challenge it with reasoning, in order to justify a significant refactor.

svachalek 2y ago

Refactoring is a terrible project plan. You never want your weekly status to be "refactored some more". Plan your other development work with enough time to refactor as you go.

lesuorac 2y ago

The ability to ship small things is I think something really missed in discussion about microservices. Like rather then refactoring the entire application to support a faster cache or something you can just add in another microservice that handles caching of the data. If some way you write the services is poor you can rewrite one of the services a new way and easily evaluate if it's actually a good idea to change the rest or not.

IshKebab 2y ago

Don't spend 100% of your time refactoring.

zingar 2y ago

I do encounter hostility but what I've realised is that it comes from experience of refactoring being done badly. "We made time for this refactoring thing but it made no difference so now we're not going to 'refactor' anymore". The worst hostility is often from management that used to be technical but never learned how to refactor effectively so they have what they think is justifiable scepticism. s/refactoring/pairing or any other technique that is good in theory but requires skill to implement. I usually find that people without technical background are willing to follow the advice of the developers that work with them, taking the things that work with them into their next roles. If refactoring worked in the beginning they'll be open to it in future, if it didn't work they'll dismiss it. Edit: also - what everyone else said - "refactoring" isn't a business goal, it's one part of achieving the goal. Achieve the goal and no-one cares how you did it. ("add a new button to that widget" isn't a business goal either so there is a tricky aspect of getting management to understand that they should be bringing you problems/goals not solutions)