Meeting 22 – Beautiful Code

We had a decent turn out to discuss Beautiful Code edited by Andy Oram. Besides me there was Graham, Tom, Steven, David, Victoria and John, of whom about half of us had read some of the book.

The book is a collection of articles and so I’d just dipped in and read whatever chapters I’d fancied, whereas some of the others had started from the start and read them in order, although no-one completed all 500+ pages.

Overall, I found it to be a bit of a mixed bag. There were some interesting chapters and some rather less so. I also thought that quite often the link to ‘beautiful code’ was a little tenuous. Often it seemed like the concept behind the code was elegant while the code itself was a little on the ugly side. Graham agreed and said that he had expected the articles to be more inspirational. David pointed to the chapter on Code Generation (Chapter 8.) as one where the code got pretty gnarly while the idea behind it was pretty.

We looked at the different chapters in a bit of a random order, so here are some of what was said about each:

David liked the chapter on Haskell and Software Transactional Memory (Chapter 24). The idea is that your code is split up into code that is guaranteed to be side-effect free and code that is not. The transactional memory is implemented in an optimistic locking style. Since you are using the side-effect free code, if you hit a conflict you simply retry. The beauty came from the way the language kept the two different types of code apart. I liked it too, but when it got to the “Santa Claus” problem I found that there was too much new stuff for a Haskell newbie such as myself.

I liked the chapter on “Beautiful Tests” (Chapter 7). The code was simple, but it showed that finding bugs in the code was actually very hard. Graham thought that it highlighted the difficulty in proving the absence of defects. It introduced the idea of test theories to help you think of circumstances that your tests don’t yet cover. An interesting metaphor was that tests are like sportsmen in that they work best in teams with each one looking after a different area.

A chapter that Graham liked was “The most beautiful code I never wrote” by Jon Bentley (Chapter 3). Unfortunately I tried to read this in bed and fell asleep. David said it reminded him of a lecture from his student days and that it had had a similar effect on him then. He liked the clever algorithms in Chapter 10 “The quest for an accelerated population count” and said that he was glad that someone had written these things down.

Michael Feather’s chapter on the design of FIT (Chapter 6) was one I liked because it showed some code that didn’t follow the traditional rules of API design but ended up with a small, clean set of classes that do what is required of them.

Last but not least, Chapter 11 “Secure Communication: The technology of Freedom” got a bit of a thumbs down. David branded it as being like someones blog on what they did on their holidays. This was the only chapter John had looked at (on the bus coming to the pub) and it had not left a good impression.

I’m sure I missed lots of good conversations, but the book is such a mixture of things that the conversation did tend to move around quite swiftly. If I missed your favourite chapter out, give it a mention in the comments…..

Meeting 11 – The Laws of Simplicity

Yet another set of people turned up for this meeting. Among the regulars were me, Graeme and Steven. Among the newcomers were Al, Mick and Jocelyn (who joined us because he knew Steven). This is probably the book which has generated the most negative responses so far, but I think it did also start off some interesting discussions…

We started out by giving our overall views on the book. Graeme said that he really liked it but that he found that laws 6 to 9 were the “bits that aren’t simple”. Mick found the book too abstract and not well formed. Both Steven and I commented that we started out liking it, but liked it less and less as we went through. Al had only read a couple of chapters and skimmed the rest. He found much of it to be obvious and made the comment that he was more useful as a tool to get him thinking about simplicity than for the actual text itself. Steven agreed with this point and found that there were too many acronyms (SHE, SLIP, BRAIN etc).

A point that was made by several people was that most of the material from the book is available on the author’s website/blog. In this context there was a feeling that it made a good blog, but not such a good book. Al found that the laws didn’t seem to form a cohesive whole and that he didn’t really understand some of them (like number 10).

Steven said he would have liked more examples of how to apply these ideas. Al agreed with this and found that the book focussed too much on the author’s anecdotes.

Looking in more detail at the topics in the book, Graeme mentioned that he would like a SLIP tool. (This acronym is introduced in the ‘Organize’ Chapter and stands for Sort, Label, Integrate, Prioritize). Al mentioned that there is such a tool but ironically it seemed over complicated and had some teething troubles.

The discussion moved onto how these laws are similar to style guides for writing. Jocelyn mentioned Michael Covington’s “How to write” (?) and “The Elements of Style”, while Al said that he’d been recommended “Bird by Bird”, but not read it. Mick said that the advice in this book was similar in that they always suggest keeping it short. “It could have been shorter!” was Graeme’s response.

I questioned the idea that savings in time feel like simplicity and wondered if savings in cost would be the same. There was no real consensus on this point. The discussion moved on to text messaging and in particular the predictive input style. This can obviously make things quicker, but Mick suggested that the problem with this is that the one time in 10 that the algorithm makes the wrong choice of word feels worse because entering the other 9 words has been so quick. Overall you have made a saving in time but you feel irritated by having to sort out its mistakes.

Finally, we moved on to a discussion of usability. Mick said that often you have to do the ‘wrong’ thing just because it is what users are used to. He suggested that only someone like Microsoft can undo these big usability mistakes because small players can’t swim against the tide. But Microsoft can completely change their user interface and be confident that they are not going to go out of business as a result. Graeme gave an example of this: Office users don’t like the new ‘ribbon’ interface even though in theory it is more usable than the old style.