Rewrite or Renovate? No-code Revitalizes Old Projects

It is a dreadful moment for a development team when the CTO says “we should rewrite the whole thing from scratch.” It is both a declaration that the current problems are bigger than you think they are and that the Pandora’s box is about to be opened, with its ensuing uncertainties. Despite often being sugarcoated as “taking a step back to leap forward,” rewriting a project rarely goes so smoothly. It is why people like Michael Fowler and Joel Spolsky are against rewriting code, with the latter even calling it the “single worst strategic mistake that any software company can make.”

The case against rewriting software is strong: First of all, it requires you to throw away the old code, with all the solutions it brought to problems. What you are throwing away in fact is, despite its shortcomings, a tried and tested solution, and a body of accumulated knowledge. Secondly, rewriting the code does not guarantee that the new one will be better. As Joel Spolsky argues, you won’t necessarily have more experience under your belt when you attack the same problem with a different team. To the contrary, you will most probably run into similar problems and the code will get messy once again, but this time your new team will be working on two projects at the same time. Thirdly, by throwing away code and starting over from scratch, you will be endangering the viability of your business if it is running on the old code. No matter how hard you and your team work, your new system will never be able to catch up with the requirements of the ongoing business, which means that you are giving up your old way of making money and won’t be able to introduce a new one for a long while. That has the potential to scuttle any business model.

For a complete rewrite to be considered feasible, starting over should cost less than just modifying the existing code, which is not the case most of the time. Michael Fowler uses the now-famous strangler fig metaphor to offer another way: “… [T]o gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled.” This approach helps mitigate the business risk and ensures that the system will keep delivering value and avoid the notorious mistake Netscape made by deciding to scrap the old structure and rewrite the code, which ended up putting them out of business.

Sometimes a wholesale rewriting of the code is not necessary. The current technology might still be considered acceptable so it might stay. Some improvement in user experience might be all that is needed. This is exactly where no-code shines. If you already have a solid data model in place, no-code lets you easily build apps on that data model. Making changes to the user interface, removing friction or offering a mobile version or responsive screens are a walk in the park with no-code. This allows you to keep your solutions to past problems without disrupting the operation of your business.

No-code allows developers to make incremental, targeted changes to the existing code structure. This approach maximizes the impact while affording developers the safety net of an already working solution. Continuing to reap the benefits of the old structure, into which a lot of time and money had been invested, and improving just the parts that need to be improved—this will be the no-code way of software renovation.