Software rewrites, to do or not to do that is the question

Software rewrites, the risks are high

What can an ISV expect when considering a software rewrite: ‘Friday the 13^th’ or ‘Back to the Future’? Everybody who has been around since the beginning of the decade remembers the Netscape
6.0 release, a rewrite from scratch, which took three years to release. Joel Spolsky, the software engineer blogger, has written extensively about this case, for example, in his article ‘Things You Should Never Do, Part I.’ The risks are high. Old code has been tested and used, many bugs have been found and fixed. The new code can potentially reintroduce the bugs that have been fixed over time and have its own new bugs. And in the meantime at Netscape, no one was paying any attention to the existing software solution nor to the competitors who gave their users new features and interesting features during the three years.

Furthermore, there are business reasons why ISVs should consider not to enter into a rewrite replacement project. As ISV you have customers who are happy using your current product. You receive license fees and maintenance, and they are the current backbone of your existence. Not all customers embrace change. Companies are like people; some are innovators and early adaptors, while the majority prefers to wait.

So why rewrite, or better said, why modernize?

I prefer to use the verb modernize, as it better describes the reasoning and process of a rewrite. But before we look at the how, we need to answer the why. The most compelling reasons are:

1. The technology is no longer supported
2. Your biggest customer(s) demand a modernized version

Most likely, if you are considering a modernization, your product has passed the maturity peak and fewer clients are signing up. This usually means that your software application has been around for quite some time. The technology on which is was built, may no longer be supported or may simply not be fit to meet modern-day requirements. It could be that some of your biggest clients are feeling restricted by the limitations what was once a highly valued product.

Call in the troops

How do you manage the extra workload of a software rewrite while keeping your current business running as usual? Your present and still satisfied customers provide a steady stream of license and maintenance revenue. They continue to need your attention. So how do you manage to modernize when you still have to maintain your current solution? Plus, how do you tackle a modernization? This is quite a specialized undertaking. How do you start:

1. Build a plan, be disciplined and stick to it. Don’t be tempted by cool technologies or increasing requests from clients.
2. Don’t assume anything and think everything through, very thoroughly.
3. Test every assumption
4. Call in the troops, the specialists who have done modernizations before

By keeping your current team on the existing product, you ensure your revenue stream and that satisfied customers remain happy. This creates the opportunity to create a new modern product based on a low-end basic package that you can gradually work up. This hybrid approach keeps your shop open while you can gradually create the new product in phases, as a big bang approach is very risky. Modernizations are sometimes unavoidable to ensure continuity in the future, so if you need to do it, do it smartly and with a pro.

Mihai Nadas
Managing Director of Yonder