The Big Rewrite

Filed under: Programming
2 Comments

Some months back, Chad Fowler wrote a series of brief posts about "The Big Rewrite"--the fateful decision that many software engineers make at various times to throw away all their existing code and start over from scratch.

The idea of the Big Rewrite is very appealing--a chance to get rid of all the hacks and mistakes and bad design choices and kludges and agglomerations and do it right from the start. But Fowler gives some pretty compelling reasons that it might be best to stifle that impulse.

Some related pieces:

I definitely understand the allure of the Big Rewrite. But I've been noticing lately that when I try to embark on a Grand Plan, a big top-down reorganizing or reworking or rebuilding of some thing or other, I never seem to finish it; among other things, the sheer weight of the amount of work to be done paralyzes me. Whereas if I can chip off a little manageable piece of revision and work on that, I may never get done with the Grand Plan but I may be able to add some very nice and useful little pieces along the way.

This is why I'm hoping to make some incremental improvements to my submission-handling process and to our database during the downtime while we're closed to subs, but why I'm not going to embark on my Grand Plan to rewrite the whole database system from scratch using the better software engineering skills and paradigms I've learned in the past five or six years.

2 Responses to “The Big Rewrite”

  1. Josh

    As a sysadmin, I’ve repeatedly come into situations where a bunch of computers were set up in a way that was causing problems, and needed to be improved, and I’ve always found it easer, cleaner, and in the end better, to set up a whole new thing from scratch rather than to try to incrementally improve things. Then again, in almost all of those situations pretty much everyone agreed that the existing situation was intolerably bad, as opposed to working ok but it sure would be nice to redesign it.

    reply

  2. jacob

    Oh, I’ve done the Big Rewrite. And I’ve done the incremental fix approach as well. I highly recommend the incremental fix.

    One of Joel’s points is that a currently more-or-less working system, no matter how kludgy, has knowledge built into it that can be hard to pull out again. The file import procedure may look like a total mess, but it got that way because we had to add support for Unix-encoded Chinese-language files, as well as for comma-delimited files that may or may not have quotes around the strings. But it just looks like a mess. So if we do a top-down rewrite, we’re definitely not going to remember to support all of that, and we’ll have to add them in later, once we figure out why certain files are breaking the system, etc. On the other hand, if you look at the existing code, and say “OK, let’s pull out everything that’s involved with parsing the file line-by-line into a separate procedure”, and you try to clean that procedure up bit-by-bit, you’ll carry the existing solutions along with you.

    It may not help you at all, but one recommendation that the Agile folks push is to start by creating a set of unit tests that prove that the code you have works. This way, you can feel free to make incremental changes without worrying that you’re breaking the code — you can run your tests at each point and be pretty sure the code is still working. Assuming your tests are good. 🙂

    And may I just say that I mostly read two kinds of blogs — blogs by my friends, and blogs about software engineering. It always pleases me when they overlap.

    reply

Join the Conversation