Beautiful Code

Chris says: This blog is about structure and architecture (including Headway's structure101) - close to "beauty in the large". See Beautiful Structure, which concludes: "The bottom line is that structure and architecture are an intrinsic part of the code, and any discussion of code "beauty" without them isn't going to work for today's monster systems."

Thanks, Chris. Link

Andrew says: Check out the delightful Edsger W. Dijkstra Archives, maintained by the University of Texas. As one of the foremost computer scientists of his generation, Dijkstra argued that programming is more a branch of mathematics than engineering. The archive is largely a collection of his handwritten notes, and range from elegant geometrical proofs to a rant about his trip to Harvard Law School. One of my favorites is his withering Answers to questions from students of Software Engineering.

Thanks, Andrew. Link

As multicore CPUs and distributed applications become the norm rather than the exception, more and more programmers are discovering that concurrent programming is a lot harder than sequential programming---so much so, in fact, that traditional "hack and patch" approaches simply don't work. Race conditions and deadlocks are hellish hard to reproduce under controlled circumstances; if you don't design and analyze concurrent systems before putting them together, the odds are long that they'll never really work.

I therefore wasn't surprised that several of the contributors to Beautiful Code chose concurrency as their topic. While beauty is desirable elsewhere, I think it's essential in the brave new parallel world the industry is rushing toward. I'd therefore like to set a challenge to readers of this blog: we'll send a free copy of the book to the 20 people who submit the most elegant, correct, solution to the problem described below by this Halloween (October 31, 2007). Answers don't have to consist of running programs---sufficiently detailed pseudocode is fine---but you must explain (a) why you believe your solution works, and (b) what makes it beautiful. You can submit your entry at the Beautiful Code wiki site; the rules of the game are given there, and below.

---

Speed Scrabble is a game for two or more players that takes only a few minutes to play. The rules are simple:

1. Spread the tiles face down on the table. Each player chooses 15 tiles at random, and puts them in front of herself; the rest are set aside.
2. Someone says "Go!" Every player turns over 7 of her tiles and starts trying to make words with them. Words must crisscross in the standard Scrabble way, and the players' "boards" are independent---each player only uses her own characters.
3. As soon as any player has made a board using all 7 of her characters, she shouts, "Go!" Every player turns over another character, so that all players now have 8 characters to use. Players may rearrange their pre-existing words when and as they please---they do not have to stick to their earlier choices.
4. When any player has used all 8 of her characters, she shouts, "Go!", and everyone turns over their ninth tile. This repeats until everyone has turned over all 15 tiles. The winner is whoever makes a legal 15-character board first.

The challenge is to design the architecture of a "referee" program for a computer Speed Scrabble tournament. Contestants will submit classes that extend an abstract base class called IPlayScrabble that the contest organizers will provide. These classes will be loaded by a SpeedScrabble program, which will create an instance of each one and pass it the dictionary of words that can be used in the game, and its first seven tiles.

Each player will run in its own thread, in parallel with its competitors. As soon as it has made a board with the tiles it has, it will request another tile from the "referee". The first player to complete a 15-tile board wins.

This is trickier than it first seems because players have to be able handle "interrupts", i.e., notice when the referee is trying to give them another tile that they didn't ask for because some other player has taken the lead. (It's often the case that a set of $N$ tiles has no solution, but an $N+1$-tile extension does, so not taking tiles as soon as they're offered is a good way to come in last.) At the same time, when the central referee is handing out tiles, it must never wait for a player to accept one before moving on to the next player, because if it takes player P two seconds to say, "Yes, thank you, carry on," that's two seconds that player P+1 has lost.

So: how will the central referee hand out characters? What methods will you give players, and which ones will they be trusted to implement themselves? Most importantly, how will you convince sceptics that your synchronization and communication scheme can't deadlock, and won't ever starve one player because of something another player has done?

In this feature article, Ian Darwin (author of O'Reilly's Java Cookbook) provides examples of Java's beautiful Reflection API, which allows your code to reach down into the JVM and do some of the same things that the Java runtime does: discover and load class files, instantiate classes, discover and invoke constructors and methods, discover and set/get fields, and more. > continue reading

One of the reasons there's less beautiful code in the world than most of us would like is that academic computer scientists don't actually seem to care much about it. Other than a lecture or two about commenting and sensible variable names, they don't talk about it in class---certainly not as much as professors of architecture talk about the esthetics of their discipline---and most journal editors never even look at their contributors' code. The result is a vicious circle: people don't think other people care about beautiful code, so they don't talk about it, so everyone believes it isn't really important.

One welcome exception is John Wiley & Sons' journal Software: Practice & Experience. Now in its thirty-seventh year, SP&E has published everything from Bourne's "A Design for a Text Editor" and first description of Make to papers on efficient plagiarism detection for large code repositories and an empirical study of Java bytecodes.

One of my favorite SP&E papers from the past few years is Jing-Chao Chen's "Building a new sort function for a C library", from 2004 [1]. You might think that sorting (at least for data sets smaller than Google's) is a solved problem; if so, Chen's abstract is worth reading in full:

Up to now, the most efficient sort function for a C library was a variant of Hoare's Quicksort (qsort, for short), which was proposed by Bentley and Mcllroy in the early 1990s. Here we call this library function BM qsort. This paper introduces a library function which is based on Chen's Proportion Extend Sort (psort). This work is inspired by the fact that psort is generally faster than qsort, and in the worst case, qsort requires O(n2) comparisons, while psort requires O(n log n). In our library function, many tricks used in BM qsort have been adopted, such as sorting a small array by an insertion sort and the handling of equal elements. Some new tricks are also proposed, however, such as the adaptive partitioning scheme. To assess more effectively the behavior of our function, the test cases are enhanced. The empirical results show that our function is robust and faster than BM qsort. On particular classes of inputs, such as 'already sorted', it is linear time.

Chen' Proportion Extended Sort doesn't outperform Quicksort in big-Oh terms---nothing could---but over the course of eighteen pages, this paper shows how and why it does better in practical terms. It's a great example of how practitioners can learn from one another, and gradually improve on one another's work. It is also, once you understand it, some very elegant code.

[1] Jin-Chao Chen: "Building a new sort function for a C library". Software: Practice & Experience, 34:777-795, April 2004.

You are a bright-eyed and bushy-tailed developer. You have just finished reading Beautiful Code and you are ready to create some beautiful code of your own. You can’t wait to put what you’ve learned into action. You fire up your IDE. As the blob of code that you’ve inherited and have to work with slowly loads, the brightness in your eyes is replaced by a glazed look. A minute later your bushy tail hangs limply in defeat. Reality sets in. Beautiful Code goes back on the shelf, next to Programming Pearls and Six-Pac Abs in Seven Days. You drink a sip of tepid coffee, sigh, and start hacking at the blob of code with the same level of energy and enthusiasm commonly displayed by those people in orange vests picking up litter on the side of the highway.

The two most common comments I’ve heard on the topic of beautiful code, following the release of the book, go something like this:

Comment 1:

“I have read a few chapters of Beautiful Code. It’s a great book, but in my job I have to maintain a ‘steaming pile of legacy code’. I don’t have many opportunities to think about beauty because I barely have time to keep the existing code functional. The best I can do it to keep crappy code from getting worse.”

Comment 2:

“Very interesting book. I wish I had an opportunity to think about cool algorithms for tough problems, but I am working on a boring enterprise application. I read stuff from a database, do something trivial to it and then I generate some reports. There aren’t that many opportunity for clever algorithms and beautiful solutions in business logic.”

It’s easy to sympathize with, and understand, both comments. The odds of finding truly beautiful code in most production systems seem to be on par with the odds of finding a well-read copy of IEEE Transactions on Software Engineering in Paris Hilton’s apartment. Furthermore, enterprise software, which represents the bulk of code in existence, deals mostly with forms, reports, etc., which – one might argue – seldom require much thinking or cleverness.

Let’s face it, the majority of code that has to be written does not offer chances for the kind of beauty and cleverness that would earn it an entry in Beautiful Code – Part II. For every opportunity to implement something cool and clever, like MapReduce (see Chapter 23), there are hundreds of blue-collar pieces of code that have to be written or maintained.

Does that mean that you should stop thinking about beautiful code in your day-to-day programming? Should you save those lofty ambitions for your after-hour pet projects – or abandon them altogether? Of course not!

The opportunities for creating a true masterpiece of coding worthy of sharing and bragging about may be rare, but you have dozens of chances everyday to make the code base you work with more beautiful – even if you are stuck working on a mortifying morass of legacy code. That’s what my series of blogs “Beautiful Code in the Real-World” will be all about.

In the next few days and weeks, I will use these blogs to share with you thoughts, strategies, and ideas for creating beauty in everyday production code – even if that code looks as if it fell off the ugly tree and hit every branch on the way down.

Make sure you come back for Part II – Scorn globally, act locally.

There’s one thing about software development that puzzles me more than anything else: talent. Some people just have it. They can crank out code and solve staggering problems, but they also have another ability which makes a huge difference. They know good design when they see it. They can tell very quickly whether a piece of code was developed thoughtfully or haphazardly; whether it’s trustworthy code or something that is ready to slide down the entropy well and deserves a good kick on the way down. They just know.

Maybe talent isn’t the right word. Maybe the right word is experience. Very experienced developers have this uncanny sense of design, but not all of them. I really don’t know whether it is learned through intense experience or fostered by innate ability but there definitely is something to it.

A long time ago, I read a book called Drawing On The Right Side of the Brain by Betty Edwards. The premise of the book is that artists see the world differently. They see things in a way which lends itself to the creation of art, and if you can mimic their mode of perception you can become more artistic.

One of the exercises in the book is to take a picture of someone’s face, turn it upside down, and then draw it. Amazingly this works very well. You are able to concentrate on curves and angles and see a face purely as shapes and textures. But, when the picture is right side up, we see it as a face and we confuse what we know about faces with what we actually see. It’s as if we have an internal monologue that goes “Oh, face. Faces are ovals; I’ll draw an oval. Hair is long and stringy; I’ll draw some lines.” But, when we get into that perceptual mode, the result is often cartoon-ish.

When I read Drawing On The Right Side of the Brain, I wondered whether there is something analogous that happens in software. Maybe very experienced designers just see things differently.

I was reminded of all of this a few years ago when another book came out, Blink by Malcolm Gladwell. In it, he argues that a lot of our cognition happens instantaneously and somewhat unconsciously. We can see this in the decision process (or lack thereof) used by experts. Often they just sort of know the answer, but they aren't quite sure how they arrived at it.

Experts can, of course, be wrong but I think that there is value in seeing things the way that an expert in a field might see them, and that if we accept the premise that arriving at better solutions is a function of being able to see them, then we have an opportunity to move design learning into a different direction. Maybe we can teach design sense or at least, design appreciation by bombarding people with examples.. here's a good snippet of code.. here's a bad one.. here's a good one.. here's a bad one.. Example after example until people grok the essence of good code.

I don't have any illusions that this sort of thing could be anything near a complete education. Some lessons have to be hard-won. Design is a deep skill, and there's no substitute for writing code and living with it for years. But, I have run into too many people who just really haven't encountered enough good code. They don't know what it looks like and they don't know why a particular piece of code is good or bad.

Next week at Agile2007, Emmanuel Gaillot and I will be hosting a workshop entitled Design Sense. We've gathered a large number of example code snippets. In the workshop, we are going to grade them and discuss them so we can learn more about what people see as good in design.. what they cue in upon. We're also interested in how much agreement there is in the community about goodness in design. If all goes well, the workshop could be the first step toward a teaching initiative that is focused on the use of these perceptual examples.

We can say that our discipline is young, but we can argue that is old also. It seems that each new generation of programmers rediscovers the past. We look at the current crop of languages and tools, and try to imagine something better and, if we have a bit of fire in us, we try to invent it but then we often find that someone else did it about 20 years ago as a research project.

This is especially true in the programming languages arena. It seems that every time someone starts down the path toward making a language simpler and more elegant, they end up at Lisp, Self, or one of the APL-ish languages. There's something elemental about those end points. We keep bumping into them.

A few years ago, I ran into something different. It was a demo of an environment called Subtext, developed by a researcher named Jonathan Edwards. Subtext is hard to describe because it contains so many ideas. One of them is that computing is more than just text. In Subtext, you edit in a larger structure, something akin to a spreadsheet. And, whenever you edit a part of your program the rest recalculates. This implies that your program contains visible example values, and that's true. The intent is to make your experience of your program immediate. You shouldn't have to guess at what your program does like you would in a purely text based language.

One of the other key ideas is that we've spent too much time vilifying cut/copy and paste in the industry. In Subtext, copy/paste is primary. In fact, it is the way that you construct programs. You copy and paste various little bits of them. The pieces you copy can maintain links to their original context; so sometimes, a copy is a bit like an extract method refactoring.

At this point, Subtext is demo, a very provocative demo, but it points in an interesting direction. There has a been a trend, recently, toward making IDEs more and more powerful. I know very few raw-Java developers these days, but I know plenty of Idea-Java programmers and Eclipse-Java programmers. These IDEs sand off the rough edges of the syntax and make Java into something else. Perhaps we need to think about how to design languages so that they are deeply amenable to IDE usage. Perhaps the future of languages is in environments like these.

Check out the Subtext demo. It's radical, but after watching it, I'm eager to see people attempt little parts of its agenda in the next generation of IDEs and languages, especially the visible example portion.

My chapter in Beautiful Code is called "Beautiful Tests". In the chapter, I focus on a specific example of how a developer can use tests to make the code not only more robust, but also more beautiful.

I really enjoyed sharing my thoughts, and thought-processes, on developer testing using lots of actual code on a very specific example. But, as I was writing this chapter, I kept feeling a strong urge to also write something at a higher-level; something a bit more general and philosophical, to complement it.

The result is The Way of Testivus - Less Unit Testing Dogma, More Unit Testing Karma, a small booklet with twelve epigrams that summarize my philosophy on developer/unit testing.

Below are two of the epigrams; if you want to read more you can download the entire "The Way of Testivus" booklet.

If you write code, write tests

The pupil asked the master programmer:

“When can I stop writing tests?”

The master answered:

“When you stop writing code.”

The pupil asked:

“When do I stop writing code?”

The master answered:

“When you become a manager.”

The pupil trembled and asked:

“When do I become a manager?”

The master answered:

“When you stop writing tests.”

The pupil rushed to write some tests. He left skid marks.

Think of code and test as one

When writing the code, think of the test.

When writing the test, think of the code.

When you think of code and test as one,

testing is easy and code is beautiful.

Simon Peyton-Jones, author of the "Beautiful Concurrency" chapter, presented this well received Haskell tutorial at OSCON.

Update: This tutorial is split up into two videos, the second part is here.

(Thanks, Brian!)