Rewriting, refactoring and resource allocation.

In a previous article I spoke about the Django software stack and how it was one of the options we were considering for developing a new product. However, all the features for the new product can be put on top of our current product Newscoop. The current tech stack for Newscoop is showing it’s age however and we need to be able to deliver new features better, faster, and cheaper. In this article we step back farther, look at the big picture and answer that ancient question: should we rewrite or refactor our code?

Definitions of rewriting and refactoring.

A number of good articles have been written on rewriting vs. refactoring software, and under what circumstances you might want to do each [1]. The consensus of these articles is that you should avoid rewriting if at all possible. Instead you should try to refactor bit by bit. So, what is the difference between a 'rewrite' and a 'refactor'?

A refactor can be done incrementally, in a way that you can keep shipping new versions, while a rewrite cannot be done incrementally.

Even if you completely replace entire pieces of your application but can keep shipping new versions, then it’s a refactor. If you have two teams essentially working on the same product, but on different code bases, then it’s a rewrite.

Resource allocation.

One thing I didn’t see mentioned in the previously cited articles is the difference in developer allocation for these two cases. Suppose you decide to rewrite your app, and you hire an equivalent number of developers to work on the rewrite. So, for example, you have five developers working on the old code and five developers working on the new code. Suppose instead that you decided to assign all of those developers to refactoring your existing application. Now you have ten developers working on one application. Which one works out better?

The answer depends on your situation, but a doubling of your workforce is something to take seriously. Sometimes you can get away with doing very little maintenance on your existing app as you write the new one. But in our case we cannot. We get 60% more people working on the project by avoiding a rewrite and have one team instead of two.

When to rewrite?

Your app is small. It will take you a few weeks or a few months to rewrite the whole thing? Not a big deal either way.
You are using outdated technology.
- Your technology is keeping you from an important market segment. For example, you implemented your web app in Flash, but now you want it to work on the iPhone. Or you have a desktop product that you now want to be available on the web.
- Your outdated programming language/technology stack makes it almost impossible to find developers (try finding Delphi developers for example).
- Developing on the technology is vastly slower(3x or more) than developing on new technology(for example, C++ vs. any memory-managed language).
Your app is slow. Your app is really slow and there is nothing you can do to speed it up using your existing architecture. Most of the time optimization and caching will solve your speed problems, but sometimes the architecture is so bad there is nothing you can do about it.
Your app isn’t extensible. Somehow you’ve written your app in a way that doesn’t allow for 3rd party plugins. This requires a judgement call in this case, as most of the time you can refactor instead.

The risks of rewriting.

A rewrite has a number of risks associated with it:

Unless both of your teams are bigger and better than the competition, then you aren’t keeping up with the rest of the market during the rewrite period.
If you are trying to keep up with the market, then you are implementing everything twice. But wait... you could have used all those developers working on the rewrite to work on new features in your existing product.
You usually can’t release the new product until it has all the features of the old one. You have two sets of developers in a race. Keeping the products in sync is a very annoying and tedious problem. The migration scripts from one product to the other need to be maintained.
Developer motivation is possibly working against you on both fronts. Developers working on the old product are thinking “what’s the point?”. Developers on the new one are thinking: “When are people going to start using this? What if the schedule slips and management pulls the plug?”.
The code you currently have is field-tested and has had all the bugs worked out. You will have to work out all a whole new set of bugs in the new version.
If your customers know you are rewriting your app, then your customers might wait for the new version and cause you to lose revenue. This is why many companies keep their plans for new products secret.
You need a lot of money to sustain yourself because you wont release anything for a long time.
Estimates are very difficult to make for a rewrite and thus your release date tends to be way off. Estimates often do not include time for integrating all of those features you are planning to implement. Developers usually can make a fairly accurate estimate for a feature if it was created in isolation, but then estimating the time for how that feature it going to be integrated into all of the other features is often way off.
Features creep in that aren’t in the original estimate (“we might as well fix this while we are at it...”).

When to refactor?

If incremental changes are possible. If there is a way to incrementally go from where you are now to your new architecture, then you should refactor instead of rewrite.
If your tech platform is still relevant. If your underlying programming language and tech platform is not outdated, refactoring is the way to go.
If your customers are being served in all target markets. You can still reach all the customers you are trying to reach with your existing tech.

Should we rewrite or refactor?

I ran sloccount on Newscoop: it says we have 25 years of person-time on it, not counting any javascript, html, css, documentation, or design work. Ok, it’s not a small app. Is it built on outdated tech? It is written in PHP, it’s not exactly outdated yet. With our technology and architecture, we can still reach all of our customers and users, even on smartphones and tablets. We don’t have a speed problem. We do, however, need more extensibility in our system in the form of a better plugin system and REST API.

We also estimated how much time it would take to implement all the features we want if we were doing a rewrite. We then estimated those same features on our existing architecture, adding in the refactoring work, but also dividing by the increased number of developers (due to having one team instead of two teams). It turns out that we can implement in half the time by doing a refactor instead of a rewrite, even with the time needed to refactor taken into account.

So even leaving out the business considerations (which are considerable), it turns out that refactoring is better deal for us in this case.

Stay tuned for an upcoming article on our new PHP technology platform.

Support our media development efforts

Who, what, when, where and why