Beautiful Code ... ?
Recently, I’ve been reading “Beautiful Code” (edited by Andy Oram & Greg Wilson). This is a collection of short papers by academics and professional software developers which explores the idea of beauty in software. I was looking forward to this, partly because we’ve just started a new course on “Software Design” and I needed some inspiration. Unfortunately, overall, I have to say that I was largely disappointed. There are a lot of articles (some 30 or so in total), so you couldn’t expect them all to be fantastic. However, whilst there were a few that I did find rather interesting, most were too detailed and often rather tedious for my liking. Certainly, I don’t really feel like I have a better idea of what beautiful code is. In fact, it really makes me ask the question: can code ever really be beautiful?
I’m going to stick my neck out now, and point out a few of the ones I really liked:
5. Correct, Beautiful, Fast (in that order): Lessons from Designing XML verifiers, Elliotte Rusty Harrold. This article focused on the design and implementation of the XML verifiers used in JDOM and XOM. The article focuses on the fact that early versions of JDOM did not verify the correctness of XML produced by applications using the library. XML is very well specified and so one can be quite precise about what constitutes valid XML. At the same time, propely understanding the XML specification is a non-trivial task. The author argues that, by leaving responsibility of generating valid XML upto library users, JDOM was failing to properly abstract away the complexity of parsing and generating XML. One reason for this was that verification was considered prohibitive to performance. The article then continues through a sequence of increasily clever optimisations that improve verification performance and, ultimately, demonstrate that you can always efficiently verify what is produced. Ultimately, it’s a great example of why you should always do things right first, and worry about performance later.
7. Beautiful Tests, Alberto Savoia. This article focuses on writing JUnit tests for a very simple piece of code — namely, binary search. The author walks through the thought process of developing a comprehensive test suite for this code, starting with the obvious (boundary conditions, edge cases, etc) and moving on to more interesting strategies. Things get interesting as the author discusses the issues faced when using randomly generated test inputs. This is a strategy I’ve used myself on many occasions, mostly because it’s often difficult to write enough test cases by hand. An important strategy which comes out of this is that of “breaking the code, to prove the tests”. That is where, assuming your code passes all your tests, you deliberately introduce bugs to make sure they are caught by the tests. This helps to refine the test suite as, most likely, some bugs you introduce will be missed at first.
15. The Long Term Benefits of Beautiful Design, Adam Kolawa. This article focused on the CERN math library LAPACK. The author’s main argument is that beauty stems from the fact that the library has been tried and trusted by many, and proven itself time and again to be an invaluable resource. His belief is that software’s main purpose is to work correctly and efficiently, and that software which stands the test of time and achieves these goals is inherently beautiful. Of course, it turns out that inside the library looks pretty good to — especially the level of commenting used to describe how each method should be used.
20. A Highly Reliable Enterprise System for NASA’s Mars Rover Mission, Ronald Mak. This articule focuses on the high-level client-server architecture found in the “Collaborative Information Portal” used by NASA scientists to to download and track information from the rovers. One of the interesting problems here, was that of “Mars Time”. That is, since the rovers are on Mars, their days are not Earth days — they’re Mars days. It turns out a Martian Day is nearly 40mins longer than an Earth day, and that there were two Martian time zones (one for each side of Mars). Online meetings and events between NASA scientists, who were distributed around the globe, were scheduled on Mars time, using the zone of the rover in question. One day, I’d love to write a program which needed to know and reason about times and dates on Mars!!
Anyway, there were a number of others which I enjoyed as well — but I’ll leave them for you to find.