The Best Software Writing I
by Joel Spolsky (Editor)

ISBN: 1590595009
Publisher: Apress
Pages: 328

The background story is: Joel Spolsky is frustrated by the low quality of writings in the software field. And he does more than complaining. His own articles and books are excellent examples of good software writings. This volume, however, does not include any essay by Joel himself. Instead Joel put together what he considers to be the best writings in the field over the last few years. All of the entries come from online sources, with Joel providing an introduction on each article. Joel's introductions serve their purpose perfectly by putting the article to come in a context. Very often the introductions themselves contain sharp and interesting points. An excellent work, as always, by Joel.

It’s hard to say much about the articles themselves. First of all it's a wild collection; the topics vary very widely and most readers will find different entries of interest. Second, as many of the articles concern the more people oriented or political side of software, almost everyone reading them will have different opinions. I will try to give you some hints:

Many people highlight Paul Graham's article "Great Hackers" as the best entry. Although I like Graham's writing in general (particularly his Lisp-related work), "Great Hackers" doesn't tell my anything interesting. Instead, my personal favorites include Ken Arnold's "Style is Substance". Arnold's idea is to make coding style a part of the language, for example standardizing the placement of the curly braces in C. This standardized style should be more than a guideline; violations should result in compilation errors. For practical reasons this is obviously never going to happen for existing mainstream languages, yet it's interesting to imagine the consequences of such a design decision. If Dennis Ritchie would have chosen this path, how much time could have been saved that's now spent on non-productive style wars and company specific style guides? Would newcomers benefit from a uniform, consistent style or would it make the language harder to learn as even more details have to be remembered? Could modern IDEs automate the task?

Another article that has generated much controversy is Bruce Eckel's "Strong Typing vs. Strong Testing". Based on his own experience, Eckel's conclusion is that programmers are simply more productive with weakly typed languages than with statically typed. As a programmer has to write unit tests anyway, statically typed languages just get in the way: "because I can get a Python program up and running in far less time than it takes you to write the equivalent C++/Java/C# program, I can start running the real tests sooner", he writes. That’s true, but the problem with Eckel's discussion is that without a scope it doesn't really convey much meaning. Any real-world project would have more constraints than the initial productivity of individual programmers and I believe that it is a mistake to assume an identical programming style in statically typed languages as in dynamical.

In the preface Joel Spolsky mentions that there were plans to make "The Best Software Writing" an annual. I do hope that vision comes true and I already look forward to the next collection.

Reviewed February 2006