I found this a surprisingly thought-provoking piece. In my day job I have been continually facing the tension between reworking and rewriting for months. The proposal to rewrite a whole core application is so tempting, and yet my experience of such rewrites is that they very rarely end up with the promised (oversold?) benefits.
Part of this, I’m sure is that the size and nature of a “complete rewrite” is that tends toward the opposite of agile, incremental development. The existing “ball of mud” provides an implicit specification of what the rewrite needs to do, and the approval of the rewrite project provides an implicit commitment to do it all in one (big) iteration by some (initially) far-off deadline based on an optimistic finger-in-the air estimate. Somehow we find ourselves back with all the things we disliked about up-front waterfall development.
It seems to me that there are several possible ways around this. One (as suggested in the article below) is to refactor rather than rewrite. To progressively improve the internal design of the application until it reaches a more maintainable state. This is definitely a good thing from a code-purist standpoint, but I have found that it can be very hard to achieve in practice. However valuable the refactoring may be in the long term, time spent doing such work does not provide immediately visible business value, and is always the first thing to be cut when resources are short or expectations are high.
An alternative approach, which I think of as the “nurse log” technique, named for the way that a fallen tree in a forest can provide a rich substrate for new saplings until eventually there is nothing left of the old tree. When using this technique for software improvement, the idea is to largely leave the old “fallen” software in place, and replace aspects of it piecemeal each time a feature is added or changed. This has the advantage that each slice of rework has a clear business benefit, but it has the disadvantage that sometimes the end result is a misshapen application, constructed to avoid the “ghost” of the old system.
A third approach is to completely ignore the existence of the old system, and treat new stories and feature requests as the prompts to make a whole new system from scratch, which does only the absolute minimum required for each story. This has the advantage that obsolete functionality will not need to be re-developed, but it has the disadvantage that it can be hard to explain to existing customers that old, familiar, features will disappear while the new solution is developed.