Kind of depressing to read because it's so accurate, yet so likely to be ignored.

I remember when Martin Fowler first published the book "Refactoring" - I was so relieved at the time because somebody with some clout that executives might actually listen to had not only identified what was wrong with software but identified a way to fix it and even gave it a name! Boy was I wrong - now you have to be careful how and when you use the term "refactor" because the people who ought to be supportive hear "wasting time".

Part of this is on developers. Refactoring is fine, but too often it turns into yak-shaving and nothing ships. The approach usually works: refactor in small steps and tie it to a feature so it’s testable and adds value.

This is on the engineers. Asking for time to refactor is like a painter asking for time to prime. It’s part of the job so just do it. When brought out in discussion, it sounds as if it is optional and its value dubious. That’s where the feeling of “wasting time” comes from.

Additionally, a lot of refactoring is about predicting the future rather than adapting the code to present expectations while keeping things easy to change. The only metric that your future self cares about is time to feedback. Refactor to adapt to present expectations while keeping the code easy to change in the future, and don’t ask for permission to do this- it is your job.

> now you have to be careful how and when you use the term "refactor" because the people who ought to be supportive hear "wasting time".

Programmers had a hand in this, sadly: https://martinfowler.com/bliki/RefactoringMalapropism.html

Nowadays people throw the term "refactoring" around quite loosely, usually meaning "rewrite" when that was not at all the original meaning of the term!

A little bit like how "vibe coding" quickly went from one definition to another even though people should have known better.

My feeling about it is that there is not a tension between refactoring and feature work but rather that a specific bit of feature work is best done with a refactoring. For instance about 10 components on a certain page I was working on all had the same accessibility problem which involved changed the HTML and then changing the CSS so this is a good chance to make a single component which can be used to replace the problematic code in all 10 components and to rationalize the CSS.

It's not a phenomenon specific to refactoring. Humans just arent good at appreciating abstract gains or abstract risks.

The proliferation of technically clueless managers of tech projects and their "control systems" such as scrum has exacerbated the problem.

I met some doctors recently that made some rhyming complaints when non-medical mba management took over a practice.

I like Fowlers writings, but honestly Refactoring is one of the worst tech books I have read.