Andy Oram and Greg Wilson
Andy Oram & Greg Wilson
We recently spoke with Andy Oram and Greg Wilson, the editors of Beautiful Code, which was released in June 2007 by O'Reilly. Beautiful Code is a collection of 33 case studies from leading computer scientists that reveal how they found unusual, carefully designed solutions to high-profile projects. O'Reilly has launched a web site devoted to Beautiful Code that provides a forum to discuss the everyday, real-world challenges programmers face on the path to proficiency and beauty. The site gives people the opportunity to discuss the book's projects and to contribute information about other projects that illustrate coding artistry.
Safari: What was the most challenging part of putting together Beautiful Code?
Wilson: Believe it or not, it was persuading people that they actually had something to contribute. Many of the authors' first reaction when we approached them was, "That sounds great, but I don't think I've ever written any code I'd call 'beautiful'."
Oram: I saw the same phenomenon, but it came across differently. Most authors liked the general idea, but I think it was hard to convey how broad a concept beauty is. Some of the resulting submissions showed a conventional kind of beauty (such as good structure and evolution with changing environments) while others might be messy or tangled but still proved to be breath-taking adaptations to difficult circumstances. Some of the submissions could have gone into a book called "Cliff-hanging code," and I think that could be a follow-on book!
Safari: How did you pick the people to feature in Beautiful Code?
Wilson: We approached as many well-known developers as we could find contact information for. Some of them were already famous for their writing; others had created, or made major contributions to, well-known open source projects, and a few were academics, or recommended by other contributors.
Oram: We also strove for diversity. In some ways we succeeded (geographic diversity, although we wish we could have gotten Chinese contributions), and in other ways we didn't meet our goals (we had only one woman author, despite strenuous recruiting efforts). We'll continue to cast as wide a net as we can with future projects.
Safari: Was it generally difficult to get the authors to participate, or were most of your choices eager to help shine some light on good coding practices?
Wilson: Most people thought it was a good idea; the real difficulty was for them to find time in their schedules. For quite a few of them, the deciding factor was our decision to donate the royalties to charity.
Safari: Beautiful Code is starting out to rave reviews, CIO Insight has included it in their 15 Must Have Books for IT Managers, and it seems to really be sparking interest from both programmers and managers. Were you surprised by all the accolades, and what aspects of the book do you think are resonating so well with readers?
Wilson: People have been complaining for at least thirty years about the fact that we teach students to write code, but we don't teach them to read it. I think that one of the reasons Beautiful Code is proving so popular is that it's a first step toward filling that gap. (And if anyone wants to fill other gaps, check out http://www.third-bit.com/notontheshelves.html.)
Oram: Readers can take heart from a general, underlying message I find in the book: that programming is an intentional, considered act, not the application of cut-and-dried rules. The rules are often relevant, but you have to be creative in their interpretation and application. Sometimes rules conflict. Then you have to either make a judgment call about which rule to adopt and which to reject, or take a leap into some solution that reconciles the conflict, which is in itself a form of nonconformism.
I think readers may have started reading the book because of the fame of many authors--there's no doubt that the initial buzz around the book came from the author list--but they soon discovered interesting background lessons like the one I just mentioned, and those kept them reading. The authors themselves seemed to enjoy recalling some project that never got the attention it deserved, and having space in which to justify the ingenious solution they or their colleagues discovered. So there's really some new material from well-known authors in this book, and no shortage of interesting history too.
Safari: What do you consider beautiful code? What are the most important attributes of well-designed code?
Wilson: I'm afraid you'll have to buy the book if you want an answer to that one ;-)
Oram: As I said, beauty can mean different things in different projects: some sacrificed portability or maintainability for speed or special environmental requirements, for instance, while the beauty in other chapters is that they reconciled requirements that seemed to be at odds.
I actually wrote up a view of beauty--not of a particular piece of code, but of how a programmer should approach the task--almost ten years ago, and realized during the course of this project that it represented my philosophical statement of what beauty in coding is:
Safari: What were some of your favorite chapters?
Wilson: Karl Fogel's description of one aspect of Subversion's internals is my personal favorite: it's exactly the kind of in-depth description of a complex-as-it-needs-to-be piece of software that undergraduate students need to see more of. I also liked Travis Oliphant's dissection of the internals of Python's Numeric module, for the same reason.
Oram: I liked the chapters into which I didn't have to put too much effort formatting them for the production team. Seriously, though, I feel professionally constrained from naming a favorite, because we asked everybody to contribute and they all worked hard. So what I like is the diversity of the whole. I express in my Afterword to the book the mind-expanding amazement I felt after reading it all. Now I would go further and say Beautiful Code is a snapshot or time capsule of programming today. Everything is there, from the timeless and elegant to the dark corners of hackerdom. The range of languages, operating systems, and other environments represented is also historic. If you read the whole book, you pretty much know what's happening across the computer field today.
Safari: Did you notice any recurring themes in all of these different descriptions of how experts solve difficult problems in software development? Are there common traits or habits among expert coders?
Wilson: Actually, the most striking thing was how diverse people's viewpoints were. Some of them focused on micro-structure, others on architecture, and a few on other things entirely (build systems, testing, structuring a code base so that it could survive years of branching and merging).
Safari: What are the biggest hurdles to writing elegant code?
Wilson:Not knowing what it looks like. Instructors tell freshmen to indent their code and use sensible variable names; a couple of years later we introduce a handful of design patterns, and that's about it. If we want programmers to write more elegant (and more robust) code, we have to make it an explicit part of their education.
Oram: I don't code large projects, but I've noticed that problem definition is a big hurdle for me, and I've read that it's true for other designers too. Make a wrong decision up front, and you can't really fix it later. Choosing a loose framework that allows a lot of modification can be smart, but it can also backfire and lead you to do a lot of coding you that someone else could have done for you.
Safari: Are there universal problems that all expert coders end up facing?
Wilson: Non-expert coders ;-)
Safari: What future trends do you see that will have on impact on the quality of code?
Wilson: Higher-level programming (e.g., the use of reflection) is quickly becoming "normal", thanks primarily to increasing use of application frameworks. In my experience, they act as amplifiers: they allow good programmers to write more beautiful code, and bad programmers to write stuff that's even uglier than it used to be.
Oram: I think that a lot of what we pass around as the received wisdom in software engineering stems from the discipline's origin in the age of stand-along programs. Web 2.0 and other kinds of distributed processing--where you don't even have control over the development of other parts of the system--may force us to re-evaluate long-held tenets of the discipline.
Safari: What did you learn from writing this book?
Wilson: That there are too many document formats out there ;-)
Oram: I'll second that one! I also found out how plain nice the leading programmers are in this field. They were tolerant of my ignorance in many areas, and of production difficulties.
Asking different authors to submit 33 chapters for review around the same time period is, as you might imagine, something of a burden on the editor. The timing was stressful, but my experiences working with the authors was joyful--and I think they felt positively too.
Safari: Tell us about what you decided to do with the royalties from Beautiful Code.
Wilson: About eight or nine years ago, I promised Frank Willison (an editor with O'Reilly) that I'd do a book with him. He passed away in 2001, so when I finally had some time to do it, I thought that donating the royalties to charity would be a nice way to remember him. A handful of people objected to the choice of Amnesty International, but I don't think there was any cause that everyone would have agreed on.
Also, I started this project at almost exactly the same time as my wife became pregnant for the first time, and I got my first copy of the book on my daughter's three-month birthday. I'd like her to grow up in a better world than the one we live in now; donating the royalties from Beautiful Code to people who are fighting injustice seemed like a good first step.
