John Fremlin's blog: The Rewrite Fallacy

Software developers love to criticise working code, say it is all very bad, and should be rewritten. It's generally possible to discourage the junior engineers who try this tactic by pointing out how big a project it would be. But some very experienced ones are looking for a big project, know that the rewrite might have few customer facing improvements, is likely to fail and come in over-budget and late, and still propose it. They claim that this time, it will be different. Why?

The upfront costs of understanding an old, working system are high and visible progress is low. The immediate visible productivity of a rewrite is high. There is the opportunity to output grand sounding designs and lots of code. Therefore the engineer will likely benefit from an unnecessary rewrite and appear productive doing it.

Unfortunately, the cost of understanding the problem domain will be borne. This will take time. Typically, there is a built in expectation that a project will be later than estimated — so paying this cost towards the end makes sense for the engineer.

The development time before the rewrite starts to benchmark itself against the prior system will look falsely productive. To counter this, as soon as possible, the design and implementation of components of the new system should be validated against production. The new systems should immediately take over responsibility as they are built, or in some way have the workload be mirrored into them, to close this window of false productivity.

Will the rewrite be a net improvement? Unless the team is very familiar with the old system, there is little reason to believe this. In fact, as the old system is working and the new one is not, at least at the moment of deciding to fund the project, then objectively the new system must be worse to start with. Hopefully, it will improve to be better over time.

Hope is a huge benefit of a rewrite. Allowing a rewrite can greatly improve morale. The blessing of this optimism has to be balanced with the curse of optimistically ignoring problems.

Rewrites are controversial and often opposed by people with responsibility for outcomes because they are a way for weak engineers to make a land grab and claim they did a good job with no accountability. Given this context, engineers might be reasonably worried about revealing issues until so much cost has been sunk that issues will not be used to cancel the project. A typical tactic for this is to claim that nothing can be measured until the whole system is built and to refuse to make even small changes to the old system, which would greatly improve matters but make the rewrite less urgent.

In my experience, a small amount of imagination and a little work is enough to run in parallel with the old system. This work is likely to be resisted but it will reduce risk and most importantly will focus efforts and align people around tangible outcomes.

It's important to set the expectation that success will not be immediate, and balance the benefits of the hope with concrete measured progress. In the best case, the confidence and ownership gained from a rewrite can outweigh the costs — it's an investment in an engineering team's level of engagement.