A bunch of times in my career over the last decade and a half, I’ve struggled with the overwhelmingness of an inherited codebase - sometimes as a Developer, sometimes as a Project Manager, and sometimes as Product Manager (I’ve spent about 1/3 of my career as each). My teams and I have often wrestled with the desire to throw out our inherited code and start over. And, when we did ‘win’ and got to start from scratch, we’ve wrestled with the slow and painful process of getting-back-to-zero. I've coached complaining teammembers and mediated heated arguments, and the thing that always helps more than anything else at those moments is this one article. The article below from Joel Spolsky in April of 2000 always helps me to keep the ThrowItAllOut part of me in check. I try to re-read it at least once a year. If you're not one of us that is old enough to remember using Netscape 4.0, and then Communicator (for about 4 seconds), and then switching to IE, I'll fill you in.
In the middle of the 1990's Netscape was dominating the Internet Browsing market. Heck, they invented it. But at the peak of their market dominance they set out to release Netscape Communicator. That release was greatly delayed. While the most experienced team in the industry was building a rock-solid and awesome Communicator from the ground up, the aging Navigator 4.0 struggled to hold Netscape's ground against Microsoft's Internet Explorer. By the time Communicator was released it was too late. The moral of the story: Don't underestimate the value of Speed To Market in software.
If you make software, this is one of those required-reading articles that we all hate reading, because we know some of it is true.
Key excerpt: "Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We're not excited by incremental renovation: tinkering, improving, planting flower beds. There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming: It’s harder to read code than to write it."
Key excerpt: “rewriting code from scratch does not make for a better code base, it makes it worse. Old code doesn't rust, it gets better… as bugs are fixed”.
The Changing World is filled with people trying to do the same things as you. So go ahead, have those heathly debates while trying to decide which of your existing things to throw out and rebuild from scratch. But make sure that when you finish, your customers aren't already using your competitor's software just because they got it to the market first.
