When Refactoring Goes Bad
collectiveidea.com
collectiveidea.com
When you get down a deep rabbit hole, you lose focus and passion. We had great things happening, but couldn’t show them to anyone since they weren’t done.
If you're going "down a deep rabbit hole" then you're doing it wrong. Refactor in small chunks. Be prepared to throw out a chunk. It's an experiment.
If your language doesn't support rapid refactoring -- this is something to think about.
Most of the time we do lots of rapid iterating (we're in Ruby and JS, mainly) and it goes great. That's why I thought it important to highlight when we do it wrong.
I've also had the experience where I pulled out a lot of the refactoring tricks from Martin Fowler's book applied them, then looked at what I did and found it had made it worse! Instead of good code, I had an "anti-pattern" sometimes called "Macaroni." Things were done, like replace conditional with polymorphism, which one would expect to result in well factored code, but instead we just chopped up the code into little pieces that didn't make much sense and fatigued us when reading and debugging.
Refactorings are experiments. Some of them need to be thrown away.
Then an hour or a week later, when I realize my idea wasn't so bad, it's easy to switch back to the branch and continue from where I left off.
Refactorings which have unlimited "Undo" and "Redo." There's also the "Change Log" which is like a DB transaction log for your code state. You don't even need to think to check in a new branch. (Mostly, you save images when you're done for now, or you want to save log-replay time.)