Synchronicity strikes again. A couple of days after I write about what I think is the responsible way to refactor, Raganwald’s del.icio.us link feed coughs up a post titled “Refactoring yourself out of business” from a blog by a chap named Eric Ries. Choice quotes:
They asked for my advice, and we went through a number of recommendations […] I thought we were having a successful conversation. Towards the end, I asked when they’d be able to make these changes, so that we could meet again and have data to look at together. I was told they weren’t sure, because all of their engineers were currently busy refactoring. You see, the code is a giant mess, has bugs, isn’t expandable, and is generally hard to modify without introducing collateral damage. In other words, it is dreaded legacy code. The engineering team […] is taking several weeks to bring it up to modern standards, including unit tests, getting started with continuous integration, and a new MVC architecture. Doesn’t that sound good?
I asked, "how much money does the company have left?" And it was this answer that really floored me. They only have enough money to last another three months.
I have no doubt that the changes the team is currently working on are good, technically sound, and will deliver the benefits they’ve claimed. Still, I think it is a very bad idea to take a large chunk of time (weeks or months) to focus exclusively on refactoring. The fact that this time is probably a third of the remaining life of the company (these projects inevitably slip) only makes this case more exaggerated.
We’re always going to have to live with legacy code. And yet it’s always dangerous to engage in large refactoring projects. In my experience, the way to resolve this tension is to follow these Rules for Refactoring:
- Insist on incremental improvements.
- Only pay for benefits to customers.
- Only make durable changes (under test coverage).
- Share what you learn.
I can’t help but notice the bulleted list looks a lot like what I was suggesting. .-)
Now, I’ve butchered the quote from Eric’s entry (sorry!) to save some space, so if my previous rant resonated with you, go read the original text – it’s far more comprehensive, and well-written.
Next up, TechCrunch has a story on why googlers quit. All is not well in the land of milk and honey. My, one might even conclude that it’s silly to expect a single employer to be the be-all, end-all workplace for every top notch techie. Really I’m just enjoying some schadenfreude, given that I suck too much to ever pass the Google hiring bar. ,-)
Back on the topic of refactoring, I’ve had an analogy in mind for a while now, between programming and cooking. Obviously, the cooking itself is the programming, but if you’ve prepared anything remotely interesting, you know the dirty dishes, cartons, plastic wrappings and ingredients you no longer need quickly accumulate into a big mess that makes the actual cooking hard. Kind of like legacy code. So continuously cleaning up after yourself is kind of like continuously refactoring while you add features.
I’m not saying that analogy really helps me when I’m programming – I already have a certain mindset for it. However, what I don’t like is cleaning up, and thinking about chores as tiny little refactorings in my home helps a bit.
How geeky is that? .-)