Rewrite (programming)

Motivations

Common motivations for rewriting software include:

• The source code is not available or is protected by an incompatible license.
• The code cannot be adapted to a new target platform; perhaps a different programming language must be used, since there is no support for the original code on the target platform.
• The code is too difficult to understand, maintain, extend or debug.
• There is a desire to use new techniques or technologies, especially when desired enhancements would require significant change.

Risks

Some warn against a total rewrite, especially under schedule constraints or competitive pressures. While developers may initially welcome the chance to correct historical design mistakes, a rewrite also discards those parts of the design that work as required. A rewrite commits the development team to deliver not just new features, but all those that exist in the previous code, while potentially introducing new bugs or regressions of previously fixed bugs. A rewrite also interferes with the tracking of unfixed bugs in the old version.

The incremental rewrite is an alternative approach, in which developers gradually replace the existing code with calls into a new implementation, expanding that implementation until it fully replaces the old one. This approach avoids a broad loss of functionality during the rewrite. Cleanroom software engineering is another approach, which requires the team to work from an exhaustive written specification of the software's functionality, without access to its code.

Examples

Netscape's project to improve HTML layout in Navigator 4 has been cited as an example of a failed rewrite. The new layout engine (Gecko) had developed independently of Navigator and did not integrate readily with Navigator's code. Hence, Navigator itself was rewritten around the new engine, breaking many existing features and delaying release by several months. Meanwhile, Microsoft focused on incremental improvements to Internet Explorer and did not face the same obstacles.

References

References

1. (6 April 2000). "Things You Should Never Do, Part I".
2. Ronkes Agerbeek, Joost. (April 15, 2005). "Never Rewrite Code From Scratch".
3. Zawinski, Jamie. "Cascade of Attention-Deficit Teenagers".
4. Tilly, Ben. (September 29, 2001). "Rewriting, from scratch, a huge code base".
5. Zawinski, Jamie. (March 31, 1999). "resignation and postmortem".