Resetting the ‘Shitty’ Counter

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.

Agile Tips: Resetting the ‘Shitty’ Counter

fallen tree acting as a nurse log

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 line of tress shows where another fell

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.


  1. I have some experience of this. In recent history (2004..2006) I rewrote half of a 60 KLOC project. The original version was too broken to analyse, but it had a handful of modules that could be reused intact.

    Whether to refactor or rewrite depends mainly on one thing. If the original application has a recognisable architecture, with discernable boundaries between components, then refactor it, else rewrite it.

    BUT: If the original application has a recognizable architecture, with discernable boundaries between components, there’s probably no need to refactor it!


  2. PS: I’ve just had the same problem with my bath!

    Change (in the form of mould) has ruined the appearance of the silicone around the side. It also leaks where it has rotted. Should I just “do up” where it is broken? That would fix the leaks but it would still look bad. Or should I reset the shitty counter, by doing it all (learning to use a mould resistant sealant)?

    Hm… decisions… In the end, I replaced all the bits you can see easily, and did up the bits you can’t. So this is a partial rewrite, with some “refactoring”, I guess. A bit of both.

    Thinking back over the last few years, this is (more or less) the solution I always apply to software as well.

Comments are closed.