||It has been suggested that this article be merged with Code refactoring. (Discuss) Proposed since May 2016.|
A rewrite in computer programming is the act or result of re-implementing a large portion of existing functionality without re-use of its source code or writing inscription. When the rewrite is not using existing code at all, it is common to speak of a rewrite from scratch. When instead only parts are re-engineered, which have otherwise become complicated to handle or extend, then it is more precise to speak of code refactoring.
A piece of software is typically rewritten when one or more of the following apply:
- its source code is not available or is only available under an incompatible license
- its code cannot be adapted to a new target platform
- its existing code has become too difficult to handle and extend
- the task of debugging it seems too complicated
- the programmer finds it difficult to understand its source code
- developers learn new techniques or wish to do a big feature overhaul which requires much change
- developers learn that new codes written may extend content options that can fix or overwrite previous problems
- the language of the source code has to be changed
Several software engineers, such as Joel Spolsky have warned against total rewrites, 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.
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 from 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. Ironically, Navigator itself was a successful cleanroom rewrite of NCSA Mosaic overseen by that program's developers. See Browser wars.
Some projects mentioning major rewrites in their history:
- Spolsky, Joel. "Things You Should Never Do, Part I". Joel on Software. Retrieved 2015-01-23.
- Ronkes Agerbeek, Joost (April 15, 2005). "Never Rewrite Code From Scratch". Retrieved 2008-09-11.
- Spolsky, Joel (April 6, 2000). "Things You Should Never Do". Retrieved 2008-09-11.
- Zawinski, Jamie. "Cascade of Attention-Deficit Teenagers". Retrieved 2008-09-11.
- Tilly, Ben (September 29, 2001). "Rewriting, from scratch, a huge code base". Retrieved 2008-09-11.
- Zawinski, Jamie (March 31, 1999). "resignation and postmortem". Retrieved 2008-09-11.