[Fishkins]

> Ah, but - in large and poorly-maintained codebase, it is always the case that some refactoring is already in progress, likely stalled for weeks, months or years as priorities have shifted without it having been completed.

This is true, and something I also thought of when reading that point. I don't think it's necessarily a counterargument, though. It's probably a better idea to spend your time helping to complete the previous refactor instead of starting your new one. Codebases in which many refactorings are started but not completed can be worse than ones that aren't refactored at all.

There could be exceptions if your new changes is very small, localized, and unlikely to interfere with the other changes going on.

[einpoklum]

> It's probably a better idea to spend your time helping to complete

> the previous refactor instead of starting your new one

That is a fair suggestion - when practicable. Often, it isn't, because of the very reasons which made the old refactor stall in the first place, e.g.:

* The target factor of the code was not such a good choice to begin with.

* The code in question is critical and any change to it is discouraged or feared.

* The code in question is the responsibility of different groups of developers / different departments, and they, or their managers, are not in the mood for collaboration.

etc.