(this is a repost of the original article at LinkedIn)
The software industry is full of training and examples on how to properly design, engineer, and code good software. What is discussed much less is how a trained software engineer should take an existing software system and convert it to a new system. There are a lot of good reasons this might need to be done: perhaps the old system relies on outdated hardware, perhaps there are licensing concerns, or perhaps it is considered insecure. Whatever the reason, this unfortunate situation is one that most software engineers should expect to see in their career.
In my experience, there are two solid approaches for a software rewrite:
- A green field approach where new software is written from scratch to replace the old system
- A 1:1 replacement where the new system tries to duplicate the precise functionality of the old system
At first glance, the first approach feels like a much better option. The old software system probably has a lot wrong with it and it is easy to envision how appealing a modern refresh would feel. Most software engineers are quick to push for green field because it grants them the opportunity to use the latest technologies. The central questions when considering this approach are: Do you know what the old system does? Do you know everything the old system does? Are you sure?
Both Netscape and Nokia are examples of how a green field rewrite can fail spectacularly (Navigator and Symbian rewrites specifically). Hopefully a development team is humble and thoughtful enough to really question and investigate what is involved in a true rewrite. Perhaps upon reflection the team will opt to go in the complete opposite direction and decide to simply convert over the existing code, creating a 1:1 exact replacement of the old system.
The biggest advantage of attempting a 1:1 replacement of an existing system is that it makes it possible to directly compare the output of the new system with that of the old. This approach opens the door to an incremental verification technique that can give the development team confidence that their replacement is no worse than the original. If the original system is very important then this becomes a completely reasonable approach.
There are downsides to a 1:1 replacement of course. In addition to giving up the opportunity to make the old software modern, this approach also brings forward all of the bugs and baggage that the old system has as well. Most depressingly, other than perhaps cutting off some licensing costs or tossing several cubic meters of old mainframe into the trash, this approach hasn’t actually made the situation any better. Well, couldn’t a team just complete a 1:1 rewrite and then improve and modernize the code later? Sadly in my experience I’ve found that once the rewrite is complete and the code is in production then it can be hard to justify further improvements or changes.
If both approaches have downsides, what about a hybrid approach? This can seem very appealing, a chance to combine the best of both worlds into a new excellent product. On the contrary, a hybrid approach is much more dangerous and fraught than either of the above approaches and it’s very likely that the team’s timeline will slide as they suffer development failure and delay. The reason is that a hybrid approach leaves nothing solid to stand on: the team can neither rely on code engineering principles nor on correctness compared to the original code.
At this point it is worth discussing the 3rd option. A 3rd option? Why wasn’t that on the original list? It wasn’t listed because no one is going to want to do it this way, no one is going to want to pay for it, and no one is going to suggest it. The approach is to replace the old system piecemeal. Though it sounds simple it is anything but: both systems must be maintained in parallel and brought into synchronization. New costs stack on top of old costs making the process very expensive with no immediate relief to look forward to. Even worse, the new and old systems eventually become intertwined and inseparable which limits cost cutting options going forward. In physical terms this approach is like building a 2nd highway to divert traffic while work is done on the original highway – very expensive but perhaps very necessary. If one is willing to accept the costs however, this approach can lead to what everyone actually wants: a new system that can do everything the old system did.
In summary, here is how I would recommend evaluating the options when it comes to replacing an existing software system:
- Replacing the old system piecemeal is generally the best approach albeit the most expensive. If you can afford to do it this way, do it this way.
- If the new system has to work (it is core to the business), opt for a 1:1 replacement.
- Green field development can produce an excellent upgrade but be prepared to lose functionality and possibly customers.
Leave a Reply