Debate: Should Architecture Rewrite be Avoided?

Posted by Sadek Drobi on May 09, 2008

Sections

Process & Practices,

Architecture & Design,

Enterprise Architecture

Topics

Enterprise Architecture ,

Design ,

Customers & Requirements ,

Architecture

Tags

Antipatterns

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.

1. Back to top

   Spolsky

   by D Fuller

   I find it interesting that Spolksy's remarks against the rewrite continue to get held up as much as they do. Firefox, which is the spinoff of the work he questioned, is the best browser in existence. Ask some of the Mozilla folks if Firefox would have been what it is today without the rewrite of the architecture.

   Reply

2. Back to top

   Re: Spolsky

   by Matt Heitzenroder

   Firefox the best browser? Maybe for extensibility, yes... but in performance? Not really - I've been using WebKit (webkit.org/) after having serious memory leaks and terrible javascript performance. WebKit is hands down the best javascript engine in the browser market. I digress tho, since it really has nothing to do with interesting article posted above.

   Reply

3. Back to top

   Re: Spolsky

   by Knut Forkalsrud

   And where is Netscape now?

   Reply

4. Back to top

   Rewrite == rework?

   by Bruce Rennie

   Is a rewrite just rework writ large? If so, it's waste, isn't it?

   Reply

5. Back to top

   Re: Spolsky

   by Ronald Miura

   I think Spolsky's point applies pretty well in commercial software, because of the cost/benefit ratio in relation to the business value/timing. For a business, waiting too many years before a release probably isn't a good strategy. In the browser market, this doesn't apply, because they are mostly free. No 'customer' was lost because of the delay. They just used the old Netscape, or switched to IE, and when the new version was released, they switched back because it was better. No cost involved for the customers. But, this strategy would be extremely risky if Netscape's business depended on Firefox's success.
   
   
   
   But it's not to say that rewrites should be avoided to all costs. There are situations where the benefits are worth the costs (I hope this is the case of the Java Plugin rewrite :)). The important thing here is that rewrites aiming for the best technical solution don't always pays off in business value.

   Reply

6. Back to top

   Re: Spolsky

   by John Dougherty

   So do you maintain that we can and should refactor a client server application to a web app rather than re-write? Clearly there are basic assumptions regarding the re-write e.g. you using the same architecture.

   Reply

• Older >