Rewrite (programming): Difference between revisions

Revision as of 07:04, 9 October 2013

Revision as of 08:26, 22 April 2014

Line 8:

*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

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

==Risks==

Several software engineers {{who|date=September 2012}} 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="spolsky">{{cite web | url=http://www.joelonsoftware.com/articles/fog0000000069.html | title=Things You Should Never Do | first=Joel | last=Spolsky | authorlink=Joel Spolsky | date=April 6, 2000 | accessdate=2008-09-11}}</ref> 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>