The first thing that grabbed me about Best Software Writing is the table of contents. Don't you just want to know "How Many Microsoft Employees Does It Take To Change A Lightbulb?" Or "What To Do When You're Screwed?" Or indeed "Starbucks Does Not Use Two-Phase Commit" Immediately it's obvious this is not a dry-as-dust tome on programming. Indeed, with the exception of Bruce Eckel's "Strong Typing vs Strong Testing" and Why The Lucky Stiff's canter through Ruby there's barely any programming at all.
What we get instead is writing about writing software, about the processes involved. For instance, Eric Lippert's punchline to the lightbulb joke is actually an amusing piece on change control. There are essays on coding. Ken Arnold argues cogently that it does not really matter which set of coding standards your project uses providing it uses something and everybody adheres to it. I agree. For a long time I have felt that the most useful tool Quest Software sells is not TOAD but PL/Formatter: it obviates all that useless time spent debating, codifying and enforcing layout standards. Apart from anything else coding standards tend to define that which can be defined - capitalisation, indentation, line breaks - when the most important things are: does the program implement the required functionality? Does it do so correctly, reliably and efficiently?
There are pieces about UI design and system design. Gregor Hohpe muses on the way Starbucks sells coffee as a metaphor for exploring messaging architecture. There are essays on project management, hiring developers, remunerating developers, outsourcing developers. There's even stuff about Sales! There are several TLA-splattered mediations on the future of the Web and the current state of the technology used to build it.
As someone who has wrestled with the issues thrown up by building a rich client interface out of JSPs I found some interesting insights in John Gruber's "The Location Field Is The New Command Line". Users want something that works, reliably, rather than something that looks pretty or comes with lots of gee-whizz features. Leon Bambrick makes the same point visually by imagining Google with MS Explorer's search interface. The corollary of this is the importance of methodologies like RAD (DSDM, XP, Agile, whatever). In order to demonstrate that our software works we must put working software in front of users on a regular basis. Otherwise we end up with requirements, specifications and acceptance tests predicated on aesthetics and the quantity of functions included.
The mix of technology is revealing. This is Spolsky's personal choice so the articles are skewed towards Microsoft's products and their technology base. There is C, C++ and VBA. There is a bit of Python and Ruby but almost no Java. There's lots of stuff about front-ends and middle tiers but nothing about databases. Certainly nothing about Oracle. Does this mean there's no good writing about databases or just that Spolsky doesn't read it? Actually, probably the former: most database writing is abstruse lectures about relational theory, uninformed witterings on normalisation or polemical rants about the inferiority of relational databases compared to object-oriented programming. Not many laughs there.
I have been calling these pieces as "essays" but they are an assemblage of various verbal constructs. There are proper essays, true. But there are also blog entries, transcriptions of conference speeches, even cartoon strips. What they have in common is that all are available on the internet. Even the Introduction is published on Joel On Software. What this means is we could click over to Google and by entering the table of contents into the location field assemble a copy of the book very cheaply (free if we print it at work, not that we would ever use our employer's paper for personal printing). So why buy the book?
Well, for a start it's got a nice colophon. And an index. Spolsky adds some insightful introductions and comments to each essay. The book is a nice size for reading on the tube or in the bath, neither of which is yet pratical with a laptop. But primarily, purchasing the book is a way of acknowledging the contribution the authors have made to the software writing community.
No comments:
Post a Comment