Rewrite (programming): Difference between revisions

Revision as of 17:32, 21 August 2013

Latest revision as of 14:33, 5 June 2025

(39 intermediate revisions by 35 users not shown)

Line 1:

{{Short description|Concept in programming}}

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]].

{{About-distinguish|code rewrites, where it is expected that the behavior will change|Code refactoring}}

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 notuses usingno 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]].

==Motivations==

A piece of software is typically rewritten when one or more of the following apply:

*its [[Orphaned work|source code is not available]] or is only available under an [[License compatibility|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

*developerdevelopers learnedlearn new techniques or wisheswish to do a big feature overhaul thatwhich requires much change

*the [[programming language]] of the source code has to be changed

*developers learn that new codes written may extend content options that can fix or overwrite previous problems

==Risks==

Several software engineers, such as [[Joel Spolsky]]<ref name=":0">{{whocite web|last1=Spolsky|first1=Joel|title=Things You Should Never Do, Part I|url=http://www.joelonsoftware.com/articles/fog0000000069.html|website=Joel on Software|date=September6 2012April 2000 |accessdate=2015-01-23}}</ref> 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 [[Software regression|regressions]] of previously fixed bugs.<ref>{{cite web | url=http://www.ronkes.nl/blog/?2005-04-15-neverrewritecode | title=Never Rewrite Code From Scratch | first=Joost | last=Ronkes Agerbeek | date=April 15, 2005 | accessdate=2008-09-11}}</ref><ref name| url-status="spolsky">{{cite webdead | urlarchiveurl=https://web.archive.org/web/20081010211819/http://www.joelonsoftwareronkes.comnl/articlesblog/fog0000000069.html?2005-04-15-neverrewritecode | titlearchivedate=Things You Should Never Do |October first=Joel | last=Spolsky | authorlink=Joel Spolsky | date=April 610, 20002008 | accessdate=2008-09-11}}</ref><ref name=":0" /> A rewrite also interferes with the tracking of unfixed bugs in the old version.<ref>{{cite web | url=http://www.jwz.org/doc/cadt.html | title=Cascade of Attention-Deficit Teenagers | first=Jamie | last=Zawinski | authorlink=Jamie Zawinski | accessdate=2008-09-11}}</ref>

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.<ref>{{cite web | url=http://www.perlmonks.org/?node_id=115511 | title=Rewriting, from scratch, a huge code base | first=Ben | last=Tilly | date=September 29, 2001 | accessdate=2008-09-11}}</ref><ref name="vorlath">{{cite web | url=http://my.opera.com/Vorlath/blog/2007/09/25/code-rewrite-yes | title=Code Rewrite - Yes | author=Vorlath | date=25 September 2007 | accessdate=2008-09-11}}</ref>

==Examples==

==Notable examples==

[[Netscape]]'s project to improve HTML layout in [[Netscape Navigator|Navigator]] 4 has been cited as an example of a failed rewrite. The new layout engine ([[Gecko (layout engine)|Gecko]]) had developed independently fromof 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.<ref name="spolsky:0" /><ref>{{cite web | url=http://www.jwz.org/gruntle/nomo.html | title=resignation and postmortem | first=Jamie | last=Zawinski | authorlink=Jamie Zawinski | date=March 31, 1999 | accessdate=2008-09-11}}</ref> Ironically, Navigator itself was a successful cleanroom rewrite of [[NCSA Mosaic]] overseen by that program's developers. See [[Browser wars]].

The [[Linux]] kernel has also been described as a successful rewrite (albeit to very different specifications) starting from [[Minix]].<ref name="vorlath"/>

==See also==

* [[Code refactoring]]

* [[Open source software development]]

* [[Technical debt]]

* [[Development hell]]

* [[Porting]]

Some projects mentioning major rewrites in their history:

{{Multicolcolbegin}}

* [[Apache HTTP Server]] (1)

* [[AOL Instant Messenger]] (1)

* [[BIND]] (1)

* [[Freenet]] (1)

* [[Fusebox (programming)|Fusebox]] (2)

* [[GNU GRUB|GRUB]] (1)

* [[Majordomo (software)|Majordomo]] (1)

* [[History of Wikipedia#Hardware and software|MediaWiki]] (1)

* [[History of Mozilla Application Suite|Mozilla/Netscape]] (1)

{{Multicol-break}}

* [[Icecast]] (0–1)

* [[netcat]] (1)

Line 48 ⟶ 41:

* [[WebObjects]] (1)

* [[Zope]] (1)

{{Multicol-endcolend}}

== Techniques ==

* [[Strangler fig pattern]]

==See also==

* [[Code refactoring]]

* [[Open source software development]]

* [[Technical debt]]

* [[Development hell]]

* [[Porting]]

* [[Game engine recreation]]

* [[Reverse engineering]]

==References==

{{reflist|30em}}

<references/>

==External links==

* {{Cite journal |last=Sneed |first=Harry |last2=Verhoef |first2=Chris |date=2019-09-01 |title=Re-implementing a legacy system |url=https://www.sciencedirect.com/science/article/pii/S0164121219301050 |journal=Journal of Systems and Software |volume=155 |pages=162–184 |doi=10.1016/j.jss.2019.05.012 |issn=0164-1212}}

* [http://www.c2.com/cgi/wiki?RewriteCodeFromScratch RewriteCodeFromScratch at C2 Wiki]

* [http://www.joelonsoftware.com/articles/fog0000000069.html Things You Should Never Do, Part I] by [[Joel Spolsky]]

[[Category:Computer programming]]