On corporate stupidity. The engineers, both hardware and software, also exhibit a reliable form of stupidity that has been known to prove terminal. From IN SEARCH OF STUPIDITY, which is the best business book I have ever read, and other than CORPORATE CANCER, which addresses an even more critical problem, possibly the most important.
SMS: Joel, what, in your opinion, is the single greatest development sin a software company can commit?
JS: Deciding to completely rewrite your product from scratch, on the theory that all your code is messy and bug-prone and is bloated and needs to be completely rethought and rebuilt from ground zero.
SMS: What’s wrong with that?
JS: Because it’s almost never true. It’s not like code rusts if it’s not used. The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it.
SMS: Well, why do programmers constantly go charging into management’s offices claiming the existing code base is junk and has to be replaced?
JS: My theory is that this happens because it’s harder to read code than to write it. A programmer will whine about a function that he thinks is messy. It’s supposed to be a simple function to display a window or something, but for some reason it takes up two pages and has all these ugly little hairs and stuff on it and nobody knows why. OK. I’ll tell you why. Those are bug fixes. One of them fixes that bug that Jill had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes a bug that occurs in low-memory conditions. Another one fixes some bug that occurred when the file is on a floppy disk and the user yanks out the diskette in the middle. That LoadLibrary call is sure ugly, but it makes the code work on old versions of Windows 95. When you throw that function away and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.
SMS: Well, let’s assume some of your top programmers walked in the door and said, “We absolutely have to rewrite this thing from scratch, top to bottom.” What’s the right response?
JS: What I learned from Charles Ferguson’s great book, High St@kes, No Prisoners, is that you need to hire programmers who can understand the business goals. People who can answer questions like “What does it really cost the company if we rewrite?” “How many months will it delay shipping the product?” “Will we sell enough marginal copies to justify the lost time and market share?” If your programmers insist on a rewrite, they probably don’t understand the financials of the company, or the competitive situation. Explain this to them. Then get an honest estimate for the rewrite effort and insist on a financial spreadsheet showing a detailed cost/benefit analysis for the rewrite.
SMS: Yeah, great, but, believe it or not, programmers have been known to, uh, “shave the truth” when it comes to such matters.
JS: What you’re seeing is the famous programmer tactic: All features that I want take 1 hour, all features that I don’t want take 99 years. If you suspect you are being lied to, just drill down. Get a schedule with granularity measured in hours, not months. Insist that each task have an estimate that is 2 days or less. If it’s longer than that, you need to break it down into subtasks or the schedule can’t be realistic.
SMS: Are there any circumstances where a complete code rewrite is justified?
JS: Probably not. The most extreme circumstance I can think of would be if you are simultaneously moving to a new platform and changing the architecture of the code dramatically. Even in this case you are probably better off looking at the old code as you develop the new code.
SMS: Hmm. Let’s take a look at your theory and compare it to some real-world software meltdowns. For instance, what happened at Netscape?
JS: Way back in April 2000, I wrote on my website that Netscape made the single worst strategic mistake that any software company can make by deciding to rewrite their code from scratch. Lou Montulli, one of the five programming superstars who did the original version of Navigator, e-mailed me to say, “I agree completely; it’s one of the major reasons I resigned from Netscape.” This one decision cost Netscape 4 years. That’s three years they spent with their prize aircraft carrier in 200,000 pieces in dry dock. They couldn’t add new features, couldn’t respond to the competitive threats from IE, and had to sit on their hands while Microsoft completely ate their lunch.