Original author here :) > Is anything ever really just a refactor, though? I think you're making the point that very few worthwhile business goals could be ac

Original author here :) > Is anything ever really just a refactor, though? I think you're making the point that very few worthwhile business goals could be achieved purely by refactoring. Which is true. Some part of the work will probably be the safe mechanical steps that make up refactoring ("replace conditional with method", "extract method" etc), and some part is "normal" "non-refactoring" change. The reason for this point is that I see developers avoid important conversations because they claim they're "just refactoring" and so they can safely make a change without involving anyone else. They're wrong unless they have a good handle on the difference between the two types of work. > it is always the case that some refactoring is already in progress When I've seen the "paused refactor" phenomenon, it isn't actually refactoring ... there's negotiation and consideration of trade-offs and impacts on various parties, because some important parts of the code need to actually do something different. But probably there are more cases in the world than I've personally seen. But really in this case I am thinking on the level of developers who will extract a method while at the same time changing the content of the code being replaced. Without running any tests, committing etc. The start and end of the one step is easily in their grasp, but they think they can save time by mixing two steps at once. > If the code is unlikely to change, there's a good chance you might want to refactor it out of your repository Interesting point. The cases that were in my head were more like unique things that wouldn't group together well with anything else. What kind of code do you typically move out of a repo? Would it be fair to say that in the case of extracting unchanging code, we're recognising that there is some difference between our intentions for the code that stays and the code that doesn't? And that by extracting it we're acting on a recognition that the intention has changed since we first wrote it? > other code _uses_ the code which never changes... And if originally the use is clunky, but you manage to improve it by your refactor Wouldn't this be more like changing my [previously] unchanging code to make it better fit the use cases of the client? > Waiting until someone (maybe even yourtself) writes tests for most code I wouldn't recommend writing tests for most of the code before any refactoring. There is certainly some small part that can be tested and then refactored while the rest stays untested and unchanged. Then on to the next test and refactor and so on. > who's to say the tests don't fail _already_? I guess I didn't mention this case explicitly, but I'd expect someone to fix the tests (or scrap the old and write _some_ new) and then get on with refactoring.