At some point, we’ve all faced it. Do we rebuild from scratch or simply refactor? With personal sites, it seems the rebuild is the default option. We see an archaic mess of code and a design that’s atrocious. So we rebuild. With a web application, that’s not always a good idea. This is a decision where it’s incredibly important not to let emotion get the best of you.
If your application is successful and profitable, a rewrite is riskier than refactoring. However, if your application hasn’t seen any significant adoption or is otherwise stagnating, a rewrite may be just what you need to breathe new life into it. Based on my experience, here’s a short list of pros and cons for rebuilding and refactoring.
Rebuilding
+ Start Clean. It seems glamorous, but it’s not necessarily a business reason. This is often more of an emotional belief that it will be better this time.
- Stagnation and long release cycle. With a complete rebuild, it’s easy for the application to appear to be stagnating even though you’re working vigorously on the new code. So now, not only do you have to catch up to your previous feature set, but you need to release something that’s a significant improvement. Otherwise, you’ve invested a lot of time in what customers would perceive as an equivalent product.
- User Revolt Changing anything dramatically in one fell swoop will invariably upset some of your customers. That can become a distraction in and of itself. I see these even when we make small focused changes, so I can only imagine what a complete rewrite would do.
- Risk of Major Bugs It introduces a lot of opportunity for bigger mistakes. Launches aren’t easy, and when you already have a significant user base, it’s nearly impossible to catch all of the edge cases prior to launching. That can lead to disappointed customers as well.
- Temptation/Scope Creep Starting from scratch makes it much easier to get distracted with shiny new tech and potential features. Building something from scratch provides very little in terms of a framework for managing scope. When the road is wide open, it’s more difficult to stay focused.
- Internally motivated vs. externally motivated. Rewrites are usually internally motivated because customers don’t see the cruft. So it’s usually the development team that wants to start over. It’s important to ask how a rewrite will directly benefit customers? If it’s not direct, then it may not be the right move.
- Discipline While you will always enter a rewrite with more knowledge and experience, writing good code requires discipline. In my opinion, refactoring is the best way to create that discipline. It’s much easier to become consistent and see repeatable results in small bits at a time. Similarly, I’ve found that it helps to look at “bad” code and learn ways to improve it. Doing a major rewrite introduces too much temptation to cut corners.
Refactoring
- Slower overall. It takes a while to start seeing meaningful results. It’s almost a leap of faith that over time things will improve meaningfully.
+ Faster cycles. With a rebuild, there’s no quick wins, but with refactoring, you can constantly be releasing updates. This helps keep morale high and also enables you to ensure your customers are regularly seeing improvements and other benefits of your work.
+ Safe. Small chunks mean minimal risk with each subsequent update. There may be bugs, but they’ll be isolated and you can quickly dive in and fix them as they’re released.
+ Repeatable. It becomes a habit, but like any habit, it takes practice. Since refactoring is about taking bite size chunks and improving them, it’s easier for it to become a habit than trying to build it from scratch.
+ Balanced with features. With refactoring, you can spend a couple of weeks behind the scenes. Then a couple of weeks on customer features. This helps alleviate any perception of a stagnant product when you’re spending time on things that customers won’t see.
+ Learning. I believe that I’ve learned more about writing good code by seeing what I did wrong and forcing myself to find/learn a better way than I would have if I had just thrown it away and started from scratch.
Recommendation
Unless there are clear business benefits like migrating to a newer technology stack that will provide more agility, increase the potential talent pool to grow your team, or simply enable you to do things that were impossible with your previous stack, I personally don’t think rewrites are the best approach. If you’re not planning on changing your technology stack, I believe you’re much better off making gradual and consistent improvements and learning as you go.
I’ve found that the best way to guide refactoring is to find the right tools to help you identify the spots that need the most attention. We’ve come to rely on two tools to help us do this. New Relic helps us identify areas that need improvement for direct customer benefit in areas like performance and reliability, and Code Climate (Ruby only) helps us identify the code smells that we should clean up so that we can make enhancements more quickly and with less risk.
I’d strongly suggest using these or other similar tools to act as an angel on your shoulder. They’ll help you identify the most important places to start and keep you focused on the right things. Regardless, I’d generally advise to be quick to refactor but slow to rebuild.
P.S. If you enjoyed this, you might like my upcoming eBook, Starting + Sustaining about bootstrapping your own web application.