An Interview with Joel Spolsky
(From the www.softwaremarketsolution.com archives)
We recently sat down with someone we regard as one of the industry's most fascinating personalities, Joel Spolsky, president and one of the founders of Fog Creek Software (www.fogcreek.com), located in New York City. Joel worked at Microsoft from 1991 to 1994 and has over ten years of experience managing the software development process. As a Program Manager on the Microsoft Excel team, Joel designed Excel Basic and drove Microsoft's Visual Basic for Applications strategy. (Joel takes particular pride in the fact that on the day Bill Gates asked if date math functions were compatible across the company's different procedure and function libraries, he, Joel Spolsky, was able to reassure the great man himself that with the exception of January and February 1900, all Microsoft application libraries counted dates the same way.)
As a Technical Manager at Juno Online Services, Joel designed and implemented many of the Internet features of Juno. His web site Joel on Software (www.JoelonSoftware.com) is read by thousands of developers worldwide every day and we strongly recommend you bookmark it as soon as you're done reading this article (oh, OK, do it now). His first book based on that site, User Interface Design for Programmers, was reviewed on this web site and we regard it as a must have and read by anyone involved in developing and marketing software.
Fog Creek Software has just released its newest and greatest product, CityDesk, a content management system. CityDesk is priced at $79 for the home version and $349 for the professional version. The product is slated to be reviewed on SoftwareMarketSolution.com shortly. (On a happy note, Joel has promised to commit ritual suicide via web cam if we discover any category one bugs in the product. With this as an incentive, we promise you a truly in-depth look at CityDesk.)
SMS: Joel, what, in your opinion, is the single greatest development sin a software company can commit?
Joel: 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 rebuild from ground zero.
SMS: What's wrong with that?
Joel: 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?
Joel: 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?
Joel: What I learned from Charles Ferguson's great book (High St@kes, No Prisoners) is that you have 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 programmer insists 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.
Joel: 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 two days or less. If it's longer than that, you need to break it down into sub-tasks or the schedule can't be realistic.
SMS: Are there any circumstances where a complete code rewrite is justified?
Joel: 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 looking at the old code as you develop the new code.
SMS: Hmmm. Let's take a look at your theory and compare it to some real world software meltdowns. For instance, what happened at Netscape?
Joel: Way back in April 2000, I wrote on my web site 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 5 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 four years and they're not really done yet. 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 threads from IE, and had to sit on their hands while Microsoft completely ate their lunch.
SMS: OK, how about Borland? Another famous meltdown. Any ideas?
Joel: Borland also got into the habit of throwing away perfectly good code and starting from scratch. Even after the purchase of Ashton-Tate, Borland bought Arago and tried to make that into dBase for Windows, a doomed project that took so long that Microsoft Access ate their lunch. With Paradox, they jumped into a huge rewrite effort with C++ and took forever to release the Windows version of the product. And it was buggy and slow where Paradox for DOS was solid and fast. Then they did it all over again with Quattro Pro, rewriting it from scratch and astonishing the world with how little new functionality it had.
SMS: Yeah, and their pricing strategy didn't help.
Joel: While I was on the Excel team, Borland cut the MSRP on QPro from around $500 to around $100. Clueless newbie that I was, I thought this was the beginning of a bloody price war. Lewis Levin, Excel BUM ("Business Unit Manager") was ecstatic. "Don't you see, Joel, once they have to cut prices, they've lost." He had no plan to respond to the lower price. And he didn't need to.
SMS: Having worked at Ashton-Tate, we have to tell you the dBase IV code base was no thing of beauty. But, we take your point. Actually, we saw this syndrome at work in Ashton-Tate's word processing division. After they bought MultiMate, they spent about two years planning a complete rewrite of the product, and wasted months evaluating new "engines" for the next version. Nothing ever happened. When a new version of the product WAS released, it was based on the same "clunky" engine everyone had been moaning about. Of course, in those two years WordPerfect and Microsoft ate Ashton-Tate's word processing lunch.
Joel: Ashton-Tate had a word processor?
SMS: Yes, but nothing good as WordStar, mind!
Joel: Hmm. That reminds me that Microsoft learned the "no rewrite" lesson the hard way. They tried to rewrite Word for Windows from scratch in a doomed project called Pyramid which was shut down, thrown away, and swept under the rug. Fortunately for Microsoft, they did this with parallel teams, and had never stopped working on the old code base, so they had something to ship, making it merely a financial disaster, not a strategic one.
SMS: OK, Lotus?
Joel: Too many MBAs at all levels and not enough people with a technical understanding of what could and needed to be built.
SMS: And I suppose building a brand new product called "Jazz" instead of getting 123 over to the Mac as quickly as possible, thus staking Microsoft to a two year lead with Excel, is an example of the same thing?
Joel: Actually they made a worse mistake: they spent something like 18 months trying to squeeze 123/3.0 into 640KB. By the time the 18 months were up, they hadn't succeeded, and in the meantime, everybody bought 386s with 4 megs. Microsoft always figured that it's better to let the hardware catch up with the software rather than spending time writing code for old computers owned by people who aren't buying much software any more.
Joel: That's an interesting case, and leads to another development sin software companies often make: using the wrong level tools for the job. At WordPerfect, everything, including everything, had to be written in Assembler. Company Policy. If a programmer needed a little one-off utility, it had to be hand-coded and hand-optimized in Assembler. They were the only people on earth writing all-Assembler apps for Windows. Insane. It's like making your ballerinas wearing chains and balls and taping their arms to their side.
SMS: What should they have been coding in?
Joel: In those days? C. Or maybe Pascal. Programmers should only use lower level tools for those parts of the product where they are adding the most value. For example, if you're writing a game where the 3D effects are your major selling point, you can't use an off the shelf 3D engine, you have to roll your own. But if the major selling point of your game is the story, don't waste time getting great 3D graphics -- just use a library. But WordPerfect was writing UI code that operates in "user time," and doesn't need to be particularly fast. Hand coded assembler is insane and adds no value.
SMS: Yes, but isn't such code tight and small? Don't products built this way avoid the dreaded "bloatware" label?
Joel: Don't get me started! If you're a software company, there are lots of great business reasons to love bloatware. For one, if programmers don't have to worry about how large their code is, they can ship it sooner. And that means you get more features, and features make users' lives better (if they use them) and don't usually hurt (if they don't). As a user, if your software vendor stops, before shipping, and spends two months squeezing the code down to make it 50% smaller, the net benefit to you is going to be imperceptible, but you went for two months without new features that you needed, and THAT hurt.
SMS: Could this possibly account for the fact that no one uses WordStar version 3.3 anymore despite despite the fact it can fit on one 1.4 meg floppy?
Joel: That and "Control-K." But seriously, Moore's law makes much of the whining about bloatware ridiculous. In 1993, Microsoft Excel 5.0 took up about $36 worth of hard drive space. In 2000, Microsoft Excel 2000 takes up about $1.03 in hard drive space. All adjusted for inflation. So stop whining about how bloated it is.
SMS: Well, we've had much personal experience with the press slamming a product we were managing. Those non-existent tables in WordStar keep coming back to mind. Somehow the fact that the product would fit on a 360K floppy just didn't seem to mean as much as the idea that the reviewer couldn't use our product to write his resume.
Joel: There's a famous fallacy that people learn in business school called the 80/20 rule. It's false, but it seduces a lot of dumb software startups. It seems to make sense. 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies. The trouble here, of course, is that it's never the same 20%. Everybody uses a different set of features. When you start marketing your "lite" product, and you tell people, "hey, it's lite, only 1MB," they tend to be very happy, then they ask you if it has word counts, or spell checking, or little rubber feet, or whatever obscure thing they can't live without, and it doesn't, so they don't buy your product.
SMS: Let's talk about product marketing and development at Microsoft. How did these two groups work together at Microsoft?
Joel: Well, in theory, the marketing group (called Product Management) was supposed to give the development team feedback on what customers wanted. Features requests from the field. That kind of stuff. In reality, they never did.
Joel: Really. Yes, we listened to customers, but not through Product Management -- they were never very good at channeling this information. So the Program Management (design) teams just went out and talked to customers ourselves. One thing I noticed pretty quickly is that you don't actually learn all that much from asking customers what features they want. Sure, they'll tell you, but it's all stuff you knew anyway.
SMS: You paint a picture of the programmer almost as a semi-deity. But in our experience, we've seen powerful technical personalities take down major companies. For instance, in The Product Marketing Handbook for Software, we describe how the development staff at MicroPro refused to add a tables capability to WordStar despite the fact that the lack of this capability was hurting sales. In our last article on SMS, in which we discuss Novell's decline and fall, we point out that one of the company's technical gods, Drew Major, refused to implement a GUI on top of Netware while you guys at Microsoft were pounding them to death with NT and a comprehensible and demonstrable interface. How do you manage situations like these?
Joel: This is a hard problem. I've seen plenty of companies with prima donna programmers who literally drive their companies into the ground. If the management of the company is technical (think Bill Gates), management isn't afraid to argue with them and win -- or fire the programmer and get someone new in. If the management of the company is not technical enough (think John Sculley), they act like scared rabbits, strangely believing that this ONE person is the only person on the planet who can write code, and it's not a long way from there to the failure of the company. If you're a non-technical CEO with programmers who aren't getting with the program, you have to bite the bullet and fire them. This is your only hope. And it means you're going to have to find new technical talent, so your chances aren't great. That's why I don't think technology companies that don't have engineers at the very top have much of a chance.
SMS: OK, let's talk about CityDesk. You just finished your beta and have released version 1.0 of the product. First, why did you decide to enter the content management marketplace? Aren't there some big players out there already?
Joel: There are, but they're ignoring the small sites. When we looked at the market last summer there was not a single content management vendor with more than 1500 installations. They don't want to talk to you if you're not going to spend $200,000. They're the mainframes, and we're the Personal Computer.
If you have a web site like SoftwareMarketSolution.com, there is no chance that you're going to spend $200,000 on content management, so there's no product for you out there. With CityDesk, you spend about $350, and you're in business. Nothing to install on the server. No expensive consultants. No programming necessary. No six-month integration project. Just an easy to use GUI Windows app that any HTMLer can set up. We call it "Desktop Content Management" in the same spirit as Quark and PageMaker, who introduced Desktop Publishing 15 years ago and grabbed 95% of the printing market. Yeah, Time Magazine won't use Desktop Publishing, and they won't use CityDesk. But the other 95% of the world will.
SMS: During the development cycle you published several interesting letters on some of the product development decisions you made. For one thing, you decided to make the product a Windows application, not a web-based system like Vignette. Why?
Joel: Two reasons. First of all, nobody really controls their web server. OK, maybe 5% of the people out there with web sites can install heavy duty software on the server, but most small publishers just have a little FTP area and that's it. So they can't use Big Iron content management.
Second, and possibly more important, because you can't build a great UI in a web browser yet. When we started building CityDesk we kept hearing the same story again and again about the Big Iron systems. They all had these web-based editing interfaces and advanced workflow. But in real life, writers and reporters universally created their content in Microsoft Word, did the workflow the old way (E-mail or "sneakernet"), and only at the very last minute had a secretary open the Word file and cut and paste it into the content management system.
Why? Because nobody wants to compose in a big TEXTAREA on an HTML page. Standalone GUI programs are fast, responsive, and have terrific UIs compared to the HTML abominations you find in web-based products.
SMS: Well, we have to agree with you on this point. In 1998, as the ASP craze was building, we consulted with some software companies who were looking to jump into the business of providing web-based "office style" software. Word processing, spreadsheets, etc. After a few minutes of using software interfaces that felt like we were running Scripsit on a circa 1978 TRS-80, we told them people would never accept this degradation in productivity and ease of use.
Joel: Did they listen to you?
SMS: Nah. They all had plenty of VC money; what did we know?
Joel: And where are these companies now?
SMS: Out of business.
Joel: I see.
SMS: Another point you made when developing CityDesk is that it uses a relational database as its backend, not an XML database. XML is the hot new thing in database structures these days. Why not use it?
Joel: XML has its advantages; it's sure a good idea for data interchange or for all those little files you need to store settings. We even use it for that. But it just can't do what a solid, multi-user, relational database can do. The next time some overpaid analyst GartnerGigaForresterStupiderMediaMetrix tells you "in the future, everything will be XML," ask them how to do "SELECT author FROM books" fast with XML. Hint: you can't. It will be slow. XML is not the way to store a lot of data.
SMS: Well, I suppose that has something to do with the fact that XML is based on SGML, a methodology for describing document structure, not data retrieval. Are you planning on releasing an Apple version? And speaking of hot things, Linux?
Joel: No to both. I'd love to have a Mac version and a Linux version, but they are not good uses of limited resources. Every dollar I invest in CityDesk Windows will earn me 20 times as many sales as a dollar invested in a hypothetical Mac version. Even if you assume that Mac has a higher percentage of creative and home users, I'm still going to sell a heck of a lot more copies on Windows than I could on Mac. And that means that to do a Mac version, the cost had better be under 10% of the cost of a Windows version. Unfortunately, that's nowhere near true for CityDesk. We benefit from using libraries that are freely available on Windows (like the Jet multi-user database engine and the DHTML edit control) for which there are no equivalents on the Macintosh.
So if anything, a Mac port would cost more than the original Windows version. Until somebody does something about this fundamental economic truth, it's hard to justify Mac versions from a business perspective. (Incidentally, I have said time and time again, if Apple wants to save the Mac, they have to change this equation.)
SMS: What do you think they can do? Any good ideas for those Macophiles out there? And what do you have against Linux? Everyone loves Linux! I mean, that cute little Penguin and all.
Joel: Apple can solve their problem for $10 million. They need to buy RealBASIC and force those smart guys at RealBASIC to make a Visual Basic compatible compiler, instead of an Almost Visual Basic compatible compiler, so that developers have SOME way to write decent Windows and Mac software with one set of source code. And they should port MFC to the Mac, too, a project that Microsoft started and buried, so that C++ programmers can port the zillions of MFC apps out there.
(People tell me "programmers should just use Java." Maybe. But Windows programmers are voting with their feet that Java doesn't allow you to build compelling enough UIs with its fairly primitive GUI libraries. Most of them would rather develop in MFC or VB and give up the Mac market than suffer through the UIs that Java makes).
SMS: Let me quote a passage from an interesting book: Open Source: The Unauthorized White Papers, by Donald Rosenberg. In speaking of the consolidation of the applications market that took place during the early 90s as Microsoft crushed WordPerfect, Lotus, and Borland, Open Source says that nothing "irritated the ISVs as much as the belief that by knowing the innards of the operating system as no one else could, Microsoft had an enormous advantage in building applications for it. ISVs longed for a level playing field."
SMS: You were at Microsoft during this critical period (at least for WordPerfect, Lotus, and Borland). Is this true? Did your knowledge of Window's innards give you an enormous advantage over your competitors?
Joel: I couldn't say that it never happened that a Microsoft application software developer asked a Windows developer for help. But I learned to program Windows from Charles Petzold's book just like everybody else, and I never had problems writing Windows programs, and if the other software companies couldn't figure out Windows programming, well, maybe they weren't very smart. Nobody ever really found the "smoking gun" -- that magic API call "MakeMyApplicationRunReallyFast()" that only Excel knew about. Andrew Schulman wrote a book where he traced exactly what Excel was doing with undocumented Windows functions, and from reading that book, it just wasn't so exciting, there was nothing they were doing that really seemed to give any competitive advantage to Excel.
That said, I don't know everything that ever happened, maybe there were some skunk works. But honestly they just weren't necessary, the Windows API was documented well enough that you could write a GUI app without any "knowledge of the innards," and the Windows team itself genuinely wanted everybody to write Windows applications and provided an awful lot of support to developers through DRG (Microsoft Developers Relations Group - Ed.).
And anyway, in the days that Excel and WinWord were written, Windows was a tiny irrelevant highly buggy set of graphics libraries and device drivers that *nobody* wanted, nothing like the monopoly it is now. Microsoft was dying to get other software companies to write for it so that it WOULD become a monopoly. It's illogical to believe that Microsoft would simultaneously be (a) trying to take over the world with Windows by getting a lot of third party apps and (b) handicapping Windows by making it impossible to do third party apps.
SMS: And a Linux version?
Joel: Linux. I don't know of anyone making money from Linux desktop software, and without making money, I can't pay programmers and rent and buy computers and T1s. I run Linux servers all over the place and it's great, but I have to eat, you know? (Editor's Note: FogCreek Software introduced -
SMS: Well, that's very capitalist of you. But speaking of software development, we note that you went through five beta releases in about six weeks time. I don't think we've ever seen such a relentless beta cycle. What were you accomplishing by this?
Joel: Sorry for the rush :) Our policy was to get to zero bugs, and re-release, rinse, and repeat until bug reports slow to almost nothing for a while. Since we don't have an installed base to pound on the software, we depended on the goodwill of beta testers to try CityDesk on new projects. For many people this meant they would spend an hour or two with the product on the day we released a new beta and then forget about it. So if we hadn't released more betas, we would be sitting around with no bugs to fix, and our beta testers would be sitting around NOT using our product, which would have wasted time.
SMS: Joel, thanks a lot. We wish you the best, and are about to release our review of the product (in January - Ed.). If we find a category one bug, how do you plan to commit ritual suicide?
Joel: I'll switch to WordPerfect 3.3, floppy-disk edition, for a month.
SMS: Actually, we were thinking of Word 1.0, the version that came bundled with PC World in 84.
(This article generated a great deal of interest and controversy, particularly on Slashdot.org. As a result , we've decided to compile some of the most trenchant criticisms of Joel's opinions and allow him to respond. This update will appear in January. We are also going to ask a prominent Open Source advocate to appear on SoftwareMarketSolution in February and give their takes on Joel and the Open Source movement.