Update, October 9, 2023:
There is no upcoming book named Brutal Refactoring. See https://www.infoq.com/podcasts/working-effectively-legacy-code/
Story time…
About six weeks ago, I was deciding whether to buy this another interesting book, or to wait for Michael Feathers’ upcoming book, “Brutal Refactoring”. But I forgot its release date, so I googled for it.
One of the top results is an article of his with the same title as his upcoming book: “Brutal Refactoring”. It was posted last 2011, about seven years after his book, “Working Effectively with Legacy Code” or WELC, was published!
Ha! He’s been preparing this book since 2011!
But in that post he said this:
“These days, I’m much more aggressive in my approach to old code. WELC was fully ingrained in that “if we don’t have tests, we can’t do much” attitude. I think that part of that was a sign of the times, and part of it was a reflection of my natural fear as a consultant. You walk in and you don’t know anything about the code base so you can’t even come close to accurately assessing risk. Nicely, though, people who are embedded in teams often can, and I’ve learned a lot from people who’ve tried things out long term in their code and have lived to tell the tale.”
… toinks!!!
It seems to me like Michael Feathers is backing out from the “Code without tests is bad code” statement from his book… since 2011!
Is he?
(To me, after reading the book, that statement meant “you should not do much refactoring if you do not have tests in place to show that your refactorings did not break anything”)
You know, I’m interested about things like this because at this moment I have been convinced that TDD is a very useful discipline for programmers (even though I have not yet used it in a real world project 
, partly because I have never been invovled yet in starting a project from scratch at work). And as a corollary to that, I am also convinced that doing things that can make us introduce TDD in a existing project later on — things such as writing tests for and refactoring an existing code base to make it more testable (and readable, of course) — is very useful and extremely helpful to software developers who are and will be working on that project. (I think they are useful not only at work but also in life outside of work — in life as a whole.)
And because of that, I am very interested in knowing if there are some [what I consider] master developers, one of whom is Michael Feathers, who have apostasized from that kind of mindset. Because if someone did, that means it’s time to rethink my stand on some things.
So, back to the quote…
It seems to me that he is saying that it’s okay for me to refactor my code base even when I do not have automated tests to show that my refactorings did not break anything, as long as I am already familiar with the code base! (Is he? Or is it just me?) If that is the case, then, Yehey! That’s the kind of mindset I had before reading WELC. But after reading WELC, whose Preface says this, …
“Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well encapsulated it is.
“With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.”
…, I feel somewhat guilty when refactoring without tests.
But even after reading WELC I still kept on doing that — refactoring without tests (with a bit of guilt of course) — because changing existing code with the goal of making it testable is a skill that cannot be learned over night. It takes time to learn it.
And worse, by the time I already know how to change my code to make it testable, I also am already very familiar with my code base and have come to realize (or have come to fool myself into thinking?) that refactoring and writing tests will be a waste of time and effort at that point in time. (Poor next developer. 
)
Okay, back to the quote again…
I hope that my initial thoughts, that Michael Feathers is backing out from his “Code without tests is bad code” statement, is not 100% accurate. I may never know until I read his upcoming book, “Brutal Refactoring : More Working Effectively with Legacy Code”, about a year from now, May 2020. I cannot wait.
Update (July 17, 2020):
Forgot about the release date again…
While googling, I found this: “Brutal refactoring, lying code, the Churn, and other emotional stories from Legacy Land” by Matthias Noback:
Working effectively with legacy code isn’t all about creating test harnesses before refactoring algorithms. The “safety first” strategy doesn’t always apply. Not if the code you’re looking at is LYING IN YOUR FACE anyway.
(here’s the video of his talk)
