Software All-Stars

A compendium of one man's idea of best writings on software has its hits and misses.

• By Mike Gunderloy
• 08/01/2005

Let us hope that the principle which Jung enunciated for Old Masters and Great Brains does not apply to writing about software. Otherwise, Joel Spolsky's latest production, The Best Software Writing I (Apress, 2005), is in definite trouble. The idea behind this book is pretty simple: Joel invited his readers to nominate the best software writing that they found littering the Internet, and then he selected the pieces that he felt were really best. The result is a collection of essays on diverse topics, with very little code in sight. But how does the end result stack up? That's the question I want to consider here, at the risk of leaving a distinct aroma of sour grapes in my own corner of the Web (after all, he didn't choose any of my writing to include).

Titles Count
That's what my thesis advisor used to remind me on a regular basis (usually when he was bouncing back one of my college essays awash in red ink). In this particular case, the title is misleading right off the bat. A more honed title would have been something like "Pretty good writing by software geeks that was published online and that Joel or his readers happened to run across." From the publishing standpoint, though, there are some problems with that title: It wouldn't fit on a book spine or in Amazon's database, and probably would have sold about as well as red t-shirts at a Democratic party convention.

Still, it's worth taking a few moments to realize what this book is not. You won't find any papers excerpted from conference proceedings here (though Adam Bosworth does sneak in a pretty informal conference talk) or academic publications. In fact, things go to the far extreme: There are comic strips and the sort of slapdash informal speculation that weblogs are littered with. That's understandable, since Joel apparently took as his mission finding things that would be fun to read, as well as things that made some interesting point about software development.

So, although Best Software Writing makes for a snappy title (and that I at the end is an obvious setup for a sequel, just like the average summer blockbuster movie ending these days), don't try to take "best" in any absolute sense. Look on it as an anthology of writing by software folks for software folks, and you'll be a lot closer to the mark.

Reaching Into the Mixed Bag
As with most anthologies, this one is a mixed bag. I personally could happily go the rest of my life without ever reading another supercilious essay by Paul Graham or suffering through another Rory Blyth comic strip. Of course, those are only personal preferences; many people find Rory's stuff uproariously funny, and for them, I am happy.

On the other hand, there's always time to read another nugget of Windows history from Raymond Chen (who writes here about backwards compatibility tweaking and why it is necessary in Windows), and without this book I wouldn't have discovered Gregor Hohpe's simple, real-world explanation of the perils of two-phase commit ("Starbucks Does Not Use Two-Phase Commit," an analogy I shall happily steal the next time I need to explain things to a new developer). But you know, it doesn't matter a whole lot that there are some things here that I don't like. With a collection of short pieces like this (29 in all) it's easy to just flip to the next one when a particular essay bores or annoys you, though if you've got a short fuse you may occasionally need to retrieve the book from across the room.

Let's talk about some of the definite highlights of the book (again, from my own idiosyncratic point of view). Eric Sink has a lovely two-parter called "Closing the Gap," the gap in question being that between the customer and your product. If you're trying to sell software, you definitely want this gap to be closed, or at least you want your customer's money to cross it. Eric is a relatively successful software guy, in terms of actually selling a product as well as building it, and here he shares a lot of good advice on sales and marketing and other skills in which many developers are utterly lacking.

On the "fun" side of the spectrum is Aaron Swartz's PowerPoint translation of Edward R. Tufte's anti-PowerPoint screed "The Cognitive Style of PowerPoint." Tufte, of course, has made part of his career out of repeating loudly that using PowerPoint makes you a stupid and bad presenter, in a manner reminiscent of those who would shut down all television with the exception of PBS and possibly the morning farm price report. Swartz reduces Tufte to slides and bullet points, and it's up to you to decide how serious he is — or how seriously he takes Tufte.

On a more serious note, Eric Lippert's "How Many Microsoft Employees Does it Take to Change a Lightbulb" is a cogent explanation of the amount of effort it takes to add five lines of code to a mature product shipped by a large corporation. Yes, your particular problem might only take five lines of code to solve. But by the time those five lines are specified and tested and localized and examined for security implications and made useful by blind Windows 95 users, the cost is staggering. That's the sort of thing you don't generally learn in school when you're using Pascal to put together a linked list so that your instructor will pat you on the head.

Moving back to the amusing side of the book, I love Leon Bambrick's skewering of the Windows Search user interface. "Aware for the Silliest User Interface: Windows Search" has nearly enough nasty things to say about that silly dog, though I would have appreciated it even more if firearms had made an appearance.

Some of the essays here edge over into the social consequences of computing. Cory Doctorow's "Save Canada's Internet from WIPO" looks at the bad effects of the notice-and-takedown approach to copyright violations (though, like much of the strident social warning stuff from the protectors of the Internet, I think it's a bit over the top). Regardless of your politics, such things are worth thinking about.

The Envelope, Please
All in all, I'd say about half the pieces in this book are, from my point of view, superior enough to warrant inclusion, and only about a third are real clunkers that should have been left on the sticky floor of the Internet. Given how opinionated I tend to be, that's a pretty darned good average for any anthology. An anthology inevitably reflects the tastes of its editor, and you should go into it expecting to have to browse around to find the high points. If I can find two or three good essays in a collection like this, I consider it worth my time, so finding a dozen or more makes this a superior product.

More importantly from the point of view of this column, how does The Best Software Writing I fit into the goal of educating developers to be better at their craft? I don't see this as a book that's going to teach anyone deep truths about software engineering, but it still has its place. The longer I spend in this field, the more I want to deal with other developers who have interests beyond the code; reading books like this can help you find the points where software touches on the rest of the world. If you want something light to browse through between heavier tomes, or a book that might provoke a few interesting lunchroom discussions around the corporate table, go for it.

Want to read more of Mike's work? Visit his Larkware site for daily updates at http://www.larkware.com.