I got my first programming job in the summer of 1982, rewriting an RSA encryption library in C for Prof. Selim Akl at Queen’s University. One of the older students eventually took pity on me and gave me a copy of Kernighan and Plauger’s Software Tools. My first reaction was, “Fortran? What’s that got to do with anything?”. But then I got past the first few pages and realized that this was exactly what I’d been looking for. Except for Wirth’s Algorithms + Data Structures = Programs, most of the other programming books I could find talked about the specifics of particular languages or systems, rather than about how to design programs or what good designs looked like. The few that did raise their sights only got as far as programming style, but with an English teacher for a father, I’d already internalized good variable names and Goldilocks modules (“not too big, not too small”).
My complaint wasn’t a new one, of course. Over the years, lots of people have pointed out that we only teach students how to write programs, not how to read them, and never show them the great programs of the past. Lions’ Commentary on Unix, Tanenbaum’s description of Minix—if you wanted to see how good programmers built things that were more than a couple of pages long, the list was pretty short.
Fast forward to 2006, when I was asked to teach a course at the University of Toronto called “CSC407: Software Architecture”. It had been created by a professor who, like me, had come to the department after many years in industry (and who, like I would later, gave up on academia after a few years and went back to the real world). I taught the course three times, then told the department to cancel it because the raw material needed to teach it properly simply didn’t exist. I must have reviewed a dozen textbooks with “Software Architecture” in their titles, but they all seemed to follow the same pattern:
- Gosh, good architecture is really important, isn’t it?
- So here’s some fuzz about high-level design principles.
- And N kinds of diagrams you can use to describe architectures.
- Um…that’s it.
- Oh, wait, we should include some examples. Wel, here’s pipe-and-filter—not an actual pipe-and-filter system, of course, just, you know, pipe-and-filter in general. And client/server, and model-view-controller, and (optionally) peer-to-peer, though again, not really truly actual existing systems.
Yes, I’m exaggerating a bit—Gorton’s Essential Software Architecture and Reekie & McAdam’s A Software Architecture Primer were both useful exceptions—but there really was a mile of clear blue water between what was in the books, and what students actually wanted and needed to know. That’s why I organized Beautiful Code: I wanted examples of good design that I could put in front of students, and more importantly, some informed discussion of why those designs were good.
BC did well, but once the dust had settled, I realized it still wasn’t exactly what I was after. I had asked contributors, “What is the most beautiful piece of software you’ve ever seen, and what makes it beautiful?” They had answered in a lot of different ways, many of which had nothing to do with “architecture” (a term I was still struggling to define). And so, last year, while at PyCon, I stood up and said, “OK, let’s fix this.” This time, though, I was more specific than I had been with BC. I told people, “Imagine that a new developer has joined your team. You have one hour to explain its architecture to them—what would you say?” That turned out to be as good a definition of “architecture” as anything else: it’s what you draw on the whiteboard when you’re telling the new guy how things fit together and why they are the way they are.
Fast forward another few weeks. Having googled my fingers to nubbins finding email addresses for people who might be able to contribute, I had enough volunteers to make the project viable. Twelve months later, after some ups and downs with publishers and a lot of help from Amy Brown, we had a book—one that’s pretty close to what my 19-year-old self wanted twenty-nine years ago.
I now realize, though, that The Architecture of Open Source Applications should be the start of something, not its culmination. There are a lot of other interesting software systems out there crying out to be described, and a lot of people who would benefit from reading those descriptions. Some of those systems are pretty crufty (yes, GDB, I’m looking at you), but that doesn’t mean they should be ignored. Every lurking horror in your favorite program was put there for a reason that made sense to someone once upon a time. We might do things differently today, but if we don’t analyze, critique, and learn from what came before, we will almost certainly do no better.
So: if you would like to make the world a better place while doing something of lasting value, and if you know enough about the innards of some reasonably well known, reasonably complicated open source application, please get in touch—we’d be happy to welcome you aboard.