Refactor or Rebuild Apps from Scratch?

We’re currently facing decisions to rebuild or refactor some of our code. So, I’ve taken to the web to uncover what others say about this question and have come up some results (frequently mixed I might add).

After a few conversations with peers and today’s reading on the subject, here are some of the key points I’ve taken away on the question of whether to rebuild code. There’s a solid discussion on Stack Overflow regarding this question as well.

Think about refactoring first because:

The previous developer has seen a lot of bugs from experiences you don’t have. Old code can be ugly, but it was done for a reason.

It’s a common and natural tendency for developers to want to rebuild an application. Most often, it’s a better usage of time and resources to refactor.

Rebuild when:

Code has become so messed that you can no longer maintain it.

Code is next to impossible to stabilize.

Any changes will set negative ripple effects through the app making them take a lot longer than they should.

Obviously, when you can adequately perceive the costs and time-value of refactoring to exceed that of a rebuild.

General advice:

Try to break off parts you are going to rebuild and do it one by one.

Rewrite code progressively, one step at a time validating you didn’t break anything.

Redesign and rewrite an application stealing snippets from the original code

I’m new to the concept of refactoring vs. rebuilding but it’s a topic of high importance. What did I miss?

I’ve faced this as a major decision at least 3 times in startups, and as a minor consideration in several other cases. The only time I chose the rewrite was when we were dealing with a social game platform built by a bunch of health care web site developers with an utterly awful architecture, and my new team had huge domain knowledge in building games. (The first game I built with that team, we refactored away from something that was pretty broken, but salvageable.)

Every other time, we’ve refactored and iterated toward the goal. There’s usually so much domain knowledge and learning embedded in code, the full rewrite is _almost_ never the right decision.

I’ve never been a big fan of rewrites, I think more often than not they don’t succeed. And not always because of the failure of the development team – there’s a lot of risk to committing a lot of time in building things back up instead of pushing things forward.

At the same time, I recognize there’s a lot of upside to doing a rebuild. It’s a tremendous boost to team morale and code ownership, and can be big technology advantage if done properly.

I generally always come into situations like this thinking refactor, and want to be convinced of doing a rewrite. Size of the code base and the phase of company factors in as well.

“The previous developer has seen a lot of bugs from experiences you don’t have. Old code can be ugly, but it was done for a reason.”

Be careful, as this reason could simply be the previous coder didn’t know the proper pattern to use in a particular case. A giant switch statement in a single file may be a rock-solid implementation of the product or feature they’ve built, but there are probably better patterns or framework features that should be used instead. And while a simple refactor might work if that’s one single case, it would be a good idea to go through the full system and view it holistically to ensure there aren’t larger systemic problems.

The right approach is often a combination of the two. Based on the changes to be made to the functionality of the application going forward, some portions of the existing code (usually a significant portion) can be refactored while you focus new development on creating what does not currently exist in terms of functionality.

It has been my experience that doing a full rewrite is definitely the exception in terms of being the right path.