As it gets more and more difficult to adapt software to new demands and requirements, the temptation to rebuild it in order to update the architecture grows stronger. The undertaking being rather risky, it is crucial to adopt the right tactics. Andy Singelton’s recent blogpost provides some insights into different tradeoffs in terms of cost, technical complexity and potential commercial risk that should be considered while choosing one or another strategy. He identifies three possible approaches and briefly highlights advantages and disadvantages of each of them:
- the “prototype and expand” option that refers to writing full new software;
- the “incremental” option based on updating some components and refactoring while still using your code base
- and the “buy” option that consists in acquiring existing software that meets new requirements.
However, several authors in the blogspace argue that the first option - rewriting software from scratch - should be avoided at all prices. Joel Spolsky advocated against such approach back in 2000, in the wake of the announcement of Netscape 6 release. He qualified the decision of Netscape to rewrite the code as “single worst strategic mistake” and provided some more illustrations of similar “mistakes”: dBase and Quattro Pro of Borland as well as Microsoft’s Pyramid project. Joel believes that in many cases the perceived need to rewrite software is very subjective and is often related to the inherent difficulty of code reuse. Moreover, he argues that much of what makes code less readable is actually related to the long process of real world testing and bug fixing:
The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. […]
Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. […]
Each of these bugs took weeks of real-world usage before they were found. […]
When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.
Joel Spolsky also stresses potential business risks of launching a rewrite project that would undermine the capacity of the team to respond to emerging market needs. Hence, according to him, even if the old code base is really bad in architectural terms, one should go for cleaning up code, refactoring and changing interface rather than launching a full scale rewrite.
One of common arguments for rewriting software is the assumption that with experience that has been gained since the first release, the team would be able to do a better job. However, Joel Spolsky highlights the fact that the developing team would most probably have changed over time. Moreover, as it was stressed by Dharmesh Shah, who more recently echoed at Spolsky’s article, there are great chances that market conditions would be changing too.
Dharmesh Shah lists other common justifications for software rewrite - e.g. bad code base or wrong initial choice of the platform or the language - and shows their limitations. He elaborates on reasons why one should resist the temptation of launching a rewrite: the process will inevitably be longer than expected; there is a major risk of not being able to respond to potential market changes and demands from existing costumers, which may undermine the competitive advantage of the software; and there are alternative solutions, e.g. refactoring that is instrumental for cleaning up the code while reducing the previous risks. Dharmesh Shah believes that rewrite is justified in only few cases: if initial technology choice prevents you from commercial success or if there is a huge shift in technology landscape - e.g. from client-server to web-based computing” - and your software cannot adapt to it.
Based on his experience of porting Quattro Pro from Modula-2 compiler to Turbo Pascal, Bob Warfield, who commented on Dharmesh Shah’s post, believes, however, that it is not worth rewriting software to change languages. He also adds some other insights on the issue, i.e. the importance of human resources especially if the decision for rebuild is taken because of the poor quality of the existing code. He further emphasize the value of refactoring suggesting that it can go beyond code and that the experience gained by the team can be used to refractor, for instance, the user model.