It’s one of those fallacious patterns in software development that though well-known to cause trouble without creating any significant benefit unfortunately ever seems to truly go away: The Software Rewrite.
In general, software developers tend to not particularly like working on old – or legacy – code, especially if it’s not been written by themselves or if they feel that due to aspects like time and budget constraints they didn’t have the opportunity to get the software architecture right from the get-go. Then on the other hand, there’s this – perfectly understandable yet to an extent detrimental – fascination with the new and shiny: Everybody loves starting and working on something new. Even if it’s not for the romantic notion that every beginning has something magical about it, starting with a clean slate allows you to work without seemingly hampering constraints imposed by existing projects. Working on a greenfield project often enables you to work with new technologies and learn something in the process.
Joel Spolsky of Stack Overflow, Microsoft Excel and Trello fame (as credentials in the software development world go you probably can’t score any higher than that) famously decried rewriting software as something you should never do citing Netscape as a prime example of how to ruin your company by trying to reproduce your existing software product without providing any additional benefit to your customers.
The gist of his argument is adequately summarised in this quote:
“When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.”
“You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.”
Legacy code isn’t just cruft that accumulated over the years for no good reasons. In part, it probably is. For the most part, however, existing code enshrines your business rules, processes and the – often otherwise implicit – knowledge of your company. In other words: It’s what makes your company special. It’s a competitive advantage that helps you succeed on the market rather than hold you back. If you ponder rewriting your software, you might just as well consider starting your business from scratch, which clearly in just about every case wouldn’t make sense. Why would you give up a (hopefully) thriving business for the lofty notion that everything will be better once you’ve tossed your tried and tested processes out of the window and replaced those with largely unproven ones? Gradually transitioning from existing ways of operating and continually adapting to new situations is crucial. You have to be changing and growing in order to continue being successful. That doesn’t mean foregoing previous knowledge, though. That knowledge is what allows you to make educated decisions about the present and the future in the first place. Legacy code is just that: Knowledge that has you make informed decisions in lieu of guesses.
Software developer Umer Mansoor has a more recent take on this matter. However, though in general he arrives at the same conclusions he admits there are situations when a rewrite perhaps does make sense. Though I still side with Spolsky in that I think you should never completely rewrite you software, it’s worth noting that “the developers didn’t like the architecture” certainly is none of those situations.