The Big Rewrite
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:
- Joel Spolsky's well-known "Things You Should Never Do, Part I," which discusses Netscape's Big Rewrite, and says that a Big Rewrite is "the single worst strategic mistake that any software company can make." Among other things, Spolsky notes that it's harder to read code than to write it.
- Speaking of reading code: Not long after that, in May of 2000, Spolsky passed along an explanation by Seth Gordon of why "Reading Code is Like Reading the Talmud."
- Adam Wiggins, contrarywise, says "Go Ahead, Do The Big Rewrite."
- Zach Baker adds some criteria for when "Rewriting Software from Scratch" is a good idea.
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.