Let's face it, most software code is rather mundane, and some is abominable, but every once in a while we come across (or create) code that is a thing of beauty – elegant and clean, solving a problem in a way that is as pleasing to the programmer's eye as a work of art.

In Beautiful Code, thirty-eight authors offer thirty-three essays on software design and authoring, in some cases dissecting code they feel is beautiful, in others walking through problems to show how they were solved elegantly, despite challenges.

We hear from Brian Kernigan, who discusses a 30 line regular expression package written by his colleague Rob Pike that he describes as a superb example of beautiful code: "compact, elegant, efficient and useful". But, he adds, it's not perfect, and he suggests a few things that could be done differently. Then, ever the teacher, he provides a list of seven assignments to challenge the reader.

Jon Bentley contributed "The Most Beautiful Code I Never Wrote", where he uses Quicksort to show how code can be made more beautiful by making it smaller. He said "In software, the most beautiful code, the most beautiful functions, and the most beautiful programs are sometimes not there at all."

Testing is rarely thought of as beautiful, but Alberto Savoia says that tests can not only be beautiful in themselves, they contribute to producing more beautiful code. He demonstrates this by describing how to test a binary search routine using the JUnit testing framework.

Unfortunately, he says, most developers are not yet what he calls "test infected" – they don't routinely create and run tests on their own code. But eXtreme Programming and other agile methodologies are helping rectify that situation, since developer involvement in testing is mandatory. JUnit's very simplicity makes it more likely to be used, which makes it beautiful.

Bryan Cantrill's "A Spoonful of Sewage" shows how one intractable bug can turn an otherwise beautiful piece of software to garbage, walking us through what he and his colleagues went through to track down and patch problems caused by a design issue in the turnstile subsystem of the Solaris kernel. Despite finding a fix that, in the words of the description, was "cheesy", the fact that no-one has found a better one over the past seven years leads Cantrill to describe the code as beautiful.

Is parallel programming beautiful? Simon Peyton Jones argues that, if we want to write parallel programs that work reliably, we must pay close attention to beauty. He said, "For me, a beautiful program is one that is so simple and elegant that it obviously has no mistakes, rather than merely having no obvious mistakes."

The approach to parallelism he advocates is called Software Transactional Memory (STM), which he explains using Haskell. A key concept: locks are bad, and STM can eliminate the problems associated with them.

Parallelism is also a key component of the chapter "Distributed Programming with MapReduce" (Google's parallel programming model). Authors Jeffrey Dean and Sanjay Ghemawat take us through the design and implementation of the model, which has been used to create over 6000 programs that process about 8 petabytes of data per day at Google.

Adam Kolawa's idea of beautiful code is simple: it should "accurately and efficiently perform the task it was designed to complete, in such a way that there are no ambiguities as to how it will behave." And to him, a prime example of beautiful code is the 30 year old mathematical library developed by CERN (the European particle physics lab).

Written in (gasp!) Fortran, the code is readable and easy to follow, something, says Kolawa, that is often lacking in "modern" programs. "The problem with the new code being written today – especially in the C++ language – is that developers use so much inheritance and overloading that it's almost impossible to tell what the code is really doing, why it's doing it, and whether it's correct," he said. "To figure this out, you need to understand all of the hierarchy of inheritance and overloading. If the operation is some kind of complicated overloaded operation, this code is not beautiful to me."

Other authors explore other facets of beauty. There's a chapter describing the development of a highly reliable, maintainable information system for the NASA Mars Rover program. There's one discussing the challenges of developing a one-button interface for the profoundly disabled, triggered by Stephen Hawking's needs. There's another on building an audio desktop for an "eyes-free" environment. There's even a chapter on making code look beautiful – or at least readable and easy to maintain.

Be warned – as you have no doubt guessed by now, this is not a book you read at a sitting. Your head would explode. There's some heavy math, and some heavy code throughout, in a mix of languages including Fortran, Haskell, Ruby, Python, Java, Perl and various flavors of C. It's best read a chapter at a time.

Some chapters will make you smile. Some will make you scratch your head, and some, I suspect, will get your hackles up. But expect to be challenged, and expect to come away with a few ideas that will help make your code more beautiful.

All royalties from Beautiful Code are being donated to Amnesty International.