When Refactoring Goes Bad
Refactoring is an important part of any software project. You should be doing small refactorings every day, and when new features demand it, major refactoring are necessary. This is a good thing, until it isn’t. Sometimes you embark on a massive refactoring only to find yourself stuck. This is one of those stories.
We launched an alpha of Fon.do over a year ago and started using it internally, and with friends and family. We were having lots of fun.
The spring and summer of 2010 saw us add more and more friends and beta users. We were so excited that we put together a complete visual redesign including the new logo. But we didn’t ship it.
As part of the redesign, we came up with fantastic new ways of writing the code, API and data storage. We branched our code and started refactoring. We switched everything to MongoDB which gave us much more flexibility under the hood. We came up with new interfaces and patterns that would make everything so much better. But we were farther than ever from shipping this new code, as more than half the app was broken. Not ideal.
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. Sometimes the best thing you can do in this situation is to cut your losses. It is far too easy to think you’re either closer to finished than you are, or that you’ll lose something by scrapping it.
We lost 5 months.
That’s from our master branch on git. We went 5 months between commits to our production code.
We had lots of work on other branches, but we weren’t shipping it. The app had stagnated and it had become difficult to continue.
We ignored our cool new rewrite branches, and went back to master. We applied the new design to it instead, and held off on larger code rewrites. It worked. In less than a month, we had deployed the new design and are back to a state of excitement. We want to work on the code again.
All the extra work we did isn’t lost. We still have it in git, and we can reference it at any time. More importantly, we discovered that some of our ideas were very good. We prototyped them, and now we can go back and re-implement them in a more incremental way (and actually ship).
Lots of projects have refactorings that go bad. That’s ok. Cut your losses, learn from your code, and start fresh. You’ll be happier.
About Daniel Morrison
Daniel founded Collective Idea in 2005 to put a name to his growing and already full-time freelance work. He works hard writing code, teaching, and mentoring.
Comments
Not to be a dick, but if you’re making huge changes and not writing/running automated tests - you’re not refactoring - you’re just changing a bunch of shit.
Refactoring is limited in scope and covered by tests - changing something while keeping the behavior the same. This sounds more like a re-write.
@Winfield: you make a good point, maybe I should call this a re-write.
However, I do often see people start down the path of a “simple refactoring” and find that they are getting farther and farther from passing tests. That in itself should be a good indicator that you’re doing something wrong.
Thanks for sharing. This has definitely happened to me, and more often than not, I end up doing the same – scrapping the refactoring work. Very painful. That said, it’s very difficult to tell when you’re on one of these paths until it’s too late.