February 14, 2010

Abhorring the Rewrite

Sam Newman has a good article sarcastically depicting why rewriting an application from scratch is rarely a good idea.  I share the same sentiment.  In fact, I think I'd go so far to say that I would strongly consider leaving a job before participating in a rewrite of an application.

Why?  Well for one, rewriting seems like a lot of time and effort to deliver a new product that simply meets the existing functionality of the old one.  And it sidesteps the real issue at hand: that the team doesn't know how to care for and improve code as it ages.

The code is difficult to work with because, for some reason or another, it wasn't continuously improved over the life of the application.  This might have been due to time constraints, not knowing how to refactor, a lack of discipline to do refactoring, or just a general lack of care for the product.  Rewriting the application from scratch doesn't address any of these issues, so you'll eventually have another codebase that's difficult to maintain.  Instead, programmers need to commit to the routine cleaning and improvement of the codebase, and management needs to support the programmers' efforts to do so.

In some ways, dealing with an aging, unwieldy codebase is like getting a knot out of a piece of rope.  You can cut the knot like Alexander and just do a rewrite, but what happens when you get another knot, which you assuredly will?  If you keep cutting, you'll eventually run out of rope.  On the other hand, you can gradually pick away at the knot, loosening small bits at a time until larger parts of  it start coming undone.  And eventually you'll have the knot removed - along with the experience and satisfaction of resolving a difficult problem.


  1. How timely. Faced with a looming rewrite in my own future, I'm mulling three different reactions:

    1. Oh well, at least I'll likely get to use some new technologies I've been wanting to use for a while.

    2. Run! It's time to find a new job.

    3. Hey, maybe now would be a good time to finally have a baby. If I get right on it, the timing might be just right for me to miss the worst of the rewrite.

    Seriously though, I can't agree with you more.

    Anyway, I'll add a link to my other favourite article on rewrites, The Big Redesign In The Sky.

    Plus, I'll add two obligatory links for any article about avoiding rewrites, both of which I know you're familiar with, but I want to mention just in case anyone ever reads this who is not familiar with them:

    Working Effectively With Legacy Code by Michael Feathers

    The Anticorruption Layer section of Domain-Driven Design by Eric Evans

  2. Hilarious! And great links. Feathers's book in particular is essential reading if you decide to skip the rewrite and improve the code you already have.