My 5 cents about refactoring.

People often postpone it, making it harder down the line.

From my experience, it's better to just do it as you go. 5 min can otherwise become 30 min thing after a while, and combined with some other 5 min thing, this can become 2 hour thing after some time, for example.

Also good luck convincing management (especially bad one), that you need 2 weeks of refactoring. Doing tiny 5 min refactoring, no one will notice.

No...

Unless you have a long-term plan.

Otherwise you're just adding changes without purpose.

Refactoring is fine, but everyone needs to be in agreement, it needs to be written up as a separate task & storypointed, and you *must* have decent testing in place before you start to make sure you haven't introduced any issues. All of the above can go wrong when it's just tacked onto the back of other tasks to try to "hide" it.

Only way you're going to come up against management issues is if you're doing so much refactoring that you're not making any other progress (in which case something has gone very wrong), or management are micro-managing the stories you're taking rather than the goals you're working towards (in which case a pretty toxic culture is likely at play.)

clients says no.

boss says no.

Everybody kicking my can down the road.

@ojt-rant why do you even ask client or boss for refactoring?

@IntrusionCM if you think refactoring has no purpose, your codebase definitely needs refactoring. Its not like "everything should be refactored" but whenever you touch something that also suitable for refactoring, you should do it. Few pros that comes to mind;
- code readability
- ease of maintaining
- ease of adding new features
- less unexpected behaivor
- fixes possible bugs

@hack No.

Or better: Yes No.

If you change sth, e.g. to fix it bug - then fixing the bug is the purpose of the change.

If you now randomly refactor stuff without a plan, you add to the bug fix several changes that might introduce new bugs / regressions / meep.

Refactoring is a necessity, but please not without a plan and communication.

No "while I'm here just randomly some code changes to make it better"...

Even worse just one GIT commit consisting of all changes (bug fix plus refactoring) so no one has a fucking idea what was actually needed vs what was additionally changed.

It's not "refactoring don't do it".

More a "refactoring with a plan and coordination".

Otherwise your pro points can all be negated, as it's most likely the other way round...

New bugs. Unexpected behaviour. No possibility to separate the intended change vs refactoring in Git history.

P A I N.

Refactoring is fine as long as it has a purpose, and is agreed upon. Many times I've seen devs refactor something they don't understand into something they THINK is easy to understand without consulting other devs.
The result is often equally hard to understand codes written in a different style. It could be worse if the refactored codes are not well covered by tests.

Tl;dr of this thread: refactoring is great, but it’s no substitute for knowing what the fuck the code is doing.