To Refactor or Rewrite A Product

There is a question that I have asked myself before, and been involved in discussions about that gets framed in the following way:

Q: At what point has a system accumulated so much technical debt that refactoring it would be a waste of time, and to rewrite it would be the better option?

Just to define some terms, from my point of view, this is how I define a Refactor vs a Rewrite:

Refactor: Rewriting the existing code in the existing code base, while the functionality remains the same.

Rewrite: The DB tables are scrapped, the architecture is changed and the code base is started fresh with zero legacy code being carried over.

There are a couple of different ways of looking at this question. There would be an engineering view of it, and I am definitely not best placed to answer it from that point of view. But as a Product Manager, I have heard those terms been thrown around many times from the dev team, especially considering when dealing with systems that have large amounts of technical debt.

Once the team have mentioned it to the Product Manager, there is a decision that then needs to be made each time a new feature request comes in for that product. Do we add to the existing infrastructure and enhance the debt, or do we wake the time to clean up the code before doing the feature?

This usually has release date impacts, which means it is up to you to weigh the benefits of taking the extra time to do the work vs getting that feature out quicker. There are many aspects and considerations that come into a decision like that. Sometimes your hands are tied (there may be a legal target date that needs to be met), sometimes there is no pressing matter to get that feature out earlier which gives you some more leeway.

That is alright for one feature, but when it gets to the point where just adding a Drop Down Box becomes a monumental task to achieve, the whole system needs to be looked at in a more holistic fashion. This is where the word “Rewrite” gets thrown around.

When it comes to a software product, it is common for 20% of the features to be used 80% of the time. This leaves us with 80% of features only being used a measly 20% of the time (we’ve all heard the 80/20 Rule before). If this product has been around for a few years, and has been accumulating technical debt, then what is the point in refactoring features that are not going to be used by the customers?

That is the point where I would consider doing a rewrite instead of a refactor. You could look at a rewrite of the existing product almost as a new beginning for that product, with different user goals. You would possibly have 3–4 years of learning’s of how the product has behaved, and by rewriting the product you are giving yourself scope to add in some new features.

As a PM, it’s all about the long game. There is no point building a product that is going to perform wonders in the short term, if it’s just going to fall over in the long term.