Rewriting Code: Success or Failure?
Every developer of some experience has seen it at least once. The evil beast of an application that should be killed with fire to rise from the ashes as a beautifully crafted phoenix. Business people dread the moment when they need to scale their team and the best new developer explains that the application is beyond maintenance and new features can only be added after a complete rewrite. If they paid attention they know that listening to this type of advice can kill their company, but they also know that not listening might do the same. When should they give in? How can you predict the outcome of such a decision? Technology evolves, faster than ever. Today’s highly productive framework is tomorrow’s legacy system that you’re locked into. If you choose to rewrite, it could very well be that the next new developer you hire after you’re done will sing the same song. If you have something that already works, why would you throw away all the investments you’ve already done? Any development team working on a product establishes some velocity of development that stabilizes after some time. What this velocity is, is determined by many factors. For example process, skills, availability, and focus have a large impact, but also technology stack and code quality of the product itself play a major role. Skills can be trained, processes can be optimized and availability and focus can be maximized. Code quality can be improved incrementally, although this can be very time-consuming in a large project of poor quality. Changing technology stack is unlikely to be possible in small increments. A rewrite can only improve things if the problem is in code quality or technology stack. Let’s look for some ways to quantify the decision.
EstimationsIf developers complain about quality or stack (and they often do) it is important to come up with an estimation to quantify the costs involved of doing or not doing the rewrite. There are two things that you need to know:
- the velocity gain so you can calculate the new cost of adding features, and
- the cost of the rewrite itself.
Estimating velocity gainBefore you choose between technology stacks, you should take them for a spin. Invest a bit in several candidates, including the existing stack, and build a small but non-trivial application with them in a spike. Having these spikes done by the same team increases the accuracy of the measurements, but it increases the time to come to a decision. This can never be hard science because the conditions of each experiment are naturally different. Once all candidates have been spiked, you should have a rough idea about the resulting code quality, the time spent, and the learning curve of the candidate. It gives you information on the relative development speed and the team needed to build on this stack.
Estimating the cost of the rewriteAfter you’ve measured the velocity gain, you know the relative velocity of each candidate. The best candidate is not necessarily the one with the highest velocity. Code quality, scalability, security, future-proofing should also be weighed. Since you’ve also spiked the existing technology, and you’ve built the application before, you can extrapolate the total effort needed. It is usually the case that rewriting is faster than doing it the first time, but for large and complex applications the gain is small. Especially if the team has changed, which is often the case. In addition, you will need to assess how much a higher velocity is going to matter business-wise. If your product is feature complete and needs no new features, you might not care at all. But if the product needs regular maintenance, increased velocity will linearly cut maintenance costs, while giving you more business flexibility. Unfortunately, experiments to measure this requires the full rewrite anyway, so you’ll have to use your gut for this one. After doing these estimations, doing the rewrite becomes a (somewhat) quantified business decision.
Taking the decision to rewrite or notFirst of all, listen to the warnings against a rewrite. Often, especially if you’re committed to the development team yourself, a rewrite seems appealing. The annoying part of your work will suddenly be gone. You won’t have to dig around that crazy code that you wrote when you should have been sleeping. This annoying part however is probably what is bringing in the cash and the fact that you wrote that code is the reason you have those (ever complaining) users now. Rewriting is probably not as appealing as it seems now. But if you are already aware of the risk, still it is important to make a well-founded decision, instead of shying away from the problem.
Are you making money?If so, you have time. The only risk of not doing the rewrite is making less money, which might be unfortunate, but not catastrophic. The time gives you the option to make reservations to keep the option of a rewrite. The more you save up, the higher the chances are you can push the rewrite through if you find you need it later. It also gives you time to slowly refactor the code, if that is still an option. If you’re not making money, these questions are important:
- do you have enough money for the rewrite?
- will having different features make your business profitable?
- can you afford to build the needed features on the existing stack?
- Code bases grow with each new feature.
- When they grow bugs are introduced.
- When bugs get fixed codebases grow further.
- Larger codebases grow bugs faster.
- Until this exponentially spirals out of control.
- And the code base goes supernova and implodes into a black hole.