Starting from scratch is often a very enticing way to shed the warts of an old code base. But the realities of trying to do this in practice, while still having to support the old code base and existing customers, often ends in disaster. However, there is usually a better way (a path less taken), especially in the computational science and engineering community.
| Resource information | Details |
|---|---|
| Blog Article Title | Things You Should Never Do, Part I |
| Authors | Joel Spolsky |
| Publication | April 6, 2000 |
The article "Things You Should Never Do, Part I" was published on Joel Spolsky's blog "Joel on Software"1 way back in April of 2000 (which might seem like an eternity ago in the software industry). In this article, Joel argues that the disastrous decision by Netscape to rewrite their browser from scratch from version 4.0 to 6.0 led to a delay of 3 years between releases and arguably led to the downfall of Netscape as the browser market share got gobbled up by competitors. (And a later analysis supported this as a major contributing factor to Netscape's downfall.2) Joel also recounts other disastrous examples from Borland and Microsoft of companies making the same mistake with other products and a case where Microsoft abandoned a green-field project and was saved by their old code base that they were able revive and ship (MS Word).
There are many reasons why these "green-field" projects usually do not go well which include: a) the developers writing the new code do not really understand all of the requirements that went into the legacy software and how important the "corner cases" actually are, b) the same team writing the new code has to also maintain the old code which slows down both efforts, and c) the development team is not really any more skilled than the initial team and the new code eventually turns out to be just as much of a mess as the legacy code it is replacing.
The blog "Joel on Software" was very popular at the time of the publication of this article and it had a significant impact on the software engineering community when it first came out.2 What is interesting is that even though this article was published over 20 years ago along with other articles about disastrous "green-field" projects, and with all of the work that has been done on refactoring3 and specifically on refactoring of legacy software4, many organizations and projects are still constantly making the costly mistake of starting from scratch over and over again. This includes many Computational Science & Engineering (CSE) projects. Note that the goal may not be to just maintain the existing software but instead to replace it. However, it is usually better to replace it incrementally one piece and one subsystem at a time.5 This typically reduces risk and uncertainty and improves return on investment. But, of course, there are cases where rewriting software from scratch may be a better choice.2, so a team should consider those factors as well before deciding to start from scratch or refactor the existing product (but most CSE teams seem to choose a rewrite-from-scratch when an incremental refactor/rewrite would have been a better choice).
In conclusion, before a CSE team or an organization decides to "cut their losses" and start over from scratch with a green-field project, they may well take some time to consider the arguments that Joel made years ago in this article and which are made by numerous other experts in the software engineering community over the years2,3,4,5 and consider if an incremental refactoring/rewriting of the existing code base might be a more successful strategy.
