Knowing and Doing

It occurred to me today that my intelligence on any given day is roughly proportional to the number of people I talk to that day:

This is true when I do department head stuff. The more people I get information from, the more people I share ideas with and get feedback from... the more I know, and the better I can do my job.

It is true when I teach. When I talk to other instructors, I learn from them, both by hearing their ideas and by expressing my ideas verbally to them. When I talk to students about our classes, whether they are in my class or not, I learn a little bit about what works, what doesn't, and what makes students tick.

It is true when I program. The agile software methods institutionalized this in the form of high degree of interaction among developers. XP raises it to the level of Standard Practice in the form of pair programming. Programmers who refuse to try pairing rarely understand what they are missing.

The value of k depends on a lot of factors, some of which are within my daily control and some of which are in my control only over longer time horizons. On a daily basis, I can seek out the best folks possible on campus and in my circle of professional colleagues available only by e-mail. Over longer time periods, I can choose the conferences I should attend, the academic communities I can participate in, and even where I want to be employed.

We all know the adages about hiring the smartest employees one can, about being the least accomplished person on the team, and so on. This is why: it increases the value of your k!

When I first attended PLoP, I was a rank novice with patterns. But like most everyone else, I had read Design Patterns -- or at least put it on my bookshelf, like everyone else -- and was just a bit in awe of the Gang of Four. Pretty soon I learned that Ralph Johnson and John Vlissides were two of the nicest and most helpful people I around. I also met Erich Gamma a time or two and found him to be a good guy, though I never interacted all that much with him. I've never had the pleasure of meeting Richard Helm.

Within a couple of years, John asked me to chair PLoP 2000. I like to have a decent understanding of something like this before I get started, and John sat with me to patiently answer questions and teach me some software patterns history. He also gave me a lot of encouragement. The conference turned out well.

Then a couple of years later, John approached me with another request: to chair the Educators Symposium at OOPSLA 2004. Again, I had been attending OOPSLA and the Educators Symposium for a few years, even helping on a few symposium committees, but I had never considered taking on the chair, which seemed like much more work and responsibility. Again, John offered me a lot of encouragement and offered to help me in any way he could in his capacity as conference chair -- including giving me his complimentary registration to OOPSLA 2003, so that I could attend the 2004 kick-off planning meeting and begin working with my colleagues to assemble the next year's program. 2003 was a tight money year for my department and me, and John's kindness made it possible for me to attend.

The 2004 Educators Symposium went pretty well, I think we can say. I've certainly talked about it enough here, beginning with this entry. I owed much of its success to John's encouragement and support. When I floated the idea of asking Alan Kay to keynote at the symposium, John said, "Dream big. I'll bet you can do it." Then, when Alan won the Turing Award, John worked to bring the Turing Award lecture to OOPSLA -- but all the while protecting my "coup" at having persuaded Alan to speak at OOPSLA 2004 in the first place. I'd've been happy to have Alan speak at OOPSLA under any circumstances, but I appreciated how John just assumed that I deserved some attention for my efforts and that, under his care, I would receive it.

John was always like that. He was a quiet leader, a person who treated each person with dignity and respect and who, as a result, could make things happen through the team he built.

He was also always a very good writer and scholar. The articles that ended up in his Pattern Hatching went a long way toward making design patterns more accessible to folks who had been a bit swamped by the GoF book. They also taught us a bit about how a good programmer thinks when he writes code.

I am filled with a deep sadness to know that John died at his home on Thanksgiving day, after more than a year and a half battling a brain tumor. He battled silently, with strength and courage derived from his abiding faith in God. My prayers are with his family, especially his wife and children.

As someone said in an announcement of John's death, the essence of John's greatness lay not in his technical accomplishments but in his humanity. He was a friend, a teacher, a colleague, and a mentor to everyone with whom he came into contact. He made everyone around him a better scholar and a better person.

Though I never did anything to deserve it, John was a friend and a mentor to me. I will miss him.

The daily grind of the department office has descended upon me the last couple of weeks, which with the exception of two enjoyable talks (described here and here) have left me with little time to think in the way that academics are sometimes privileged. Now comes a short break full of time at home with family.

Here are a few things that have crossed my path of late:

• Belated "Happy Birthday" to GIMP, which turned 10 on Monday, November 21, 2005. There is a lot of great open-source software out there, much of which is older than GIMP, but there's something special to me about this open-source program for image manipulation. Most of the pros use Photoshop, but GIMP is an outstanding program for a non-trivial task that shows how far an open-source community can take us. Check out the original GIMP announcement over at Google Groups.

• Then there is this recently renamed oldie but goodie on grounded proofs. My daughters are at the ages where they can appreciate the beauty of math, but their grade-school courses can do only so much. Teaching them bits and pieces of math and science at home, on top of their regular work, is fun but challenging.

  The great thing about explaining something to a non-expert is that you have to actually understand the topic.

  Content and method both matter. Don't let either the education college folks or the "cover all the material" lecturers from the disciplines tell you otherwise.

• Very cool: an on-line version of John Von Neumann's Theory of Self-Reproducing Automata.

• Finally, something my students can appreciate as well as I:

  If schedule is more important than accuracy, then I can always be on time.

  Courtesy of Uncle Bob, though I disagree with his assumption that double-entry bookkeeping is an essential practice of modern accounting. (I do not disagree with the point he makes about test-driven development!) Then again, most accountants hold double-entry bookkeeping in nearly religious esteem, and I've had to disagree with them, too. But one of my closest advisors as a graduate student, Bill McCarthy, is an accountant with whom I can agree on this issue!

Ernie's 3D Pancakes picked up on the We're Doomed theme from our OOPSLA panel. There are many good blogs written by theoretical computer scientists; I especially enjoy 3D Pancakes, Computational Complexity, and The Geomblog. Recently, the CS theory community has been discussing how to communicate the value and importance of theory and algorithms to the broader CS community, the research funding agencies, and the general public, and they've struck on some of the same ideas some of my colleagues and I have been batting around concerning CS more generally. Check those blogs out for some thought-provoking discussions.

Anyway, I found the comments on Ernie's entry that quotes me quoting Owen to be worth reading. It's good to be reminded occasionally how diverse the set of CS programs is. Michael Stiber's comment (sixth in the list) points out that CS department's have themselves to blame for many of these problems. One of my department colleagues was just at my door talking about missed opportunities to serve the university community with computing courses that matter to them. Pretty soon, we see courses like this filling a very mainstream corner of the market, and people in other departments hungering for courses in the newly-developed markets that Owen points out.

"How may of us really need to rewrite BLAS, LAPACK, etc., routines?"

None. But how many students are taught to write them anyway?

And this quote speaks to the much simpler issue of how to revise our curriculum for majors. How much tougher it is for us to re-imagine what we should be doing for non-computer scientists and then figuring out how to do it.

I just realized that by "simple" I mean that we computer scientists at least have some control over our own domain. In many ways, the task of reforming the major curriculum is tougher due to the tight cultural constraints of our community. I imagine that CS is no different than any discipline in this regard. We are a young discipline and used to the rapid change of technology -- perhaps we can find a way to become more nimble. certainly, having the conversation is a first step.

Two enjoyable talks in one week -- a treat!

On Tuesday, I went to the 2005 CHFA Faculty Excellence Award lecture. (CHFA is UNI's College of Humanities and Fine Arts.) The winner of the award was Roy Behrens, whose name long-time readers of this blog may recognize from past entries on a non-software patterns of design and 13 Books. Roy is a graphic arts professor at my university, and his talk reflected both his expertise in design and the style that contributed to his winning an award for faculty excellence. He didn't use PowerPoint in that stultifying bullet-point way that has afflicted the science and technology for the last decade or more... They used high-resolution images of creative works and audio to create a show that amplified his words. They also demonstrated a wonderful sense of "visual wit".

The title of the talk was teaching as a SUBVERSIVE INACTIVITY: a miscellany, in homage to Neil Postman's famous book. When he was asked to give this talk, he wondered what he should talk about -- how to teach for 34 years without burning out? He decided to share how his teaching style has evolved away from being the center of attention in the classroom toward giving students the chance to learn.

The talk opened with pivotal selections from works that contributed to his view on teaching. My favorite from the bunch came from "The Cult of the Fact" by Liam Hudson, a British psychologist: The goal of the teacher is to

... transmit an intellectual tradition of gusto, and instill loyalty to it, ...

Behrens characterized his approach to teaching in terms of Csikszentmihalyi's model of Flow: creativity and productivity happen when the students' skills are within just the right range of the challenges given to them.

(After seeing this talk, I'm almost afraid to use my homely line art in a discussion of it. Roy's images were so much better!)

He called this his "Goldilocks Model", the attempt to create an environment for students that maximizes their chance to get into flow.

What followed was a collage of images and ideas. I enjoyed them all. Here are three key points about teaching and learning from the talk.

Aesthetic and Anesthetic

What Csikszentmihalyi calls flow is roughly comparable to what we have historically called "aesthetic". And in its etymological roots, the antonym of 'aesthetic' is anesthetic. What an interesting juxtaposition in our modern language!

In what ways can the atmosphere of our classrooms be anesthetic?

We often think of boredom as a teaching anesthetic, but it's useful to trace this back to the possibility that the boredom results from a lack of challenge. Even more important is to remember that too much challenge, too much activity, what amounts to too much distraction also serves as an anesthetic. People tend to tune out when they are overstimulated, as a coping mechanism. I am guessing that when I bore students the most, it's more likely to be from a mayhem of ideas than a monotony. ("Let's sneak in one more idea...)

Behrens is a scholar of patterns, and he has found it useful to teach students patterns -- linguistic and visual -- suitable to their level of development, and then turn them lose in the world. Knowing the patterns changes our vision; we see the world in a new way, as an interplay of patterns.

Through patterns, students see style and begin to develop their own. 'Style' is often maligned these days as superficial, but the idea of style is essential to understanding designs and thinking about creating. That said, style doesn't determine quality. One can find quality in every genre of music, of painting. There is something deeper than style. Teaching our principles of programming languages course this semester as I am, I hope that my students are coming to understand this. We can appreciate beautiful object-oriented programs, beautiful functional programs, beautiful logic programs, and beautiful procedural programs.

Creativity as Postmodern

Behrens didn't use "postmodern", but that's my shorthand description of his idea, in reference to ideas like the scrapheap challenge.

During the talk, Behrens several times quoted Arthur Koestler's The Act of Creation. Here's one:

The creative process is an "unlikely marriage of cabbages and kings -- of previously unrelated frames of reference or universes of discourse -- whose union will solve the previously insoluble problem." -- Koestler

Koestler's "cabbages and kings" is an allusion to a nonsense poem in Alice in Wonderland. (Remember what Alan Perlis said about "Alice": The best book on programming for the layman ...; but that's because it's the best book on anything for the layman.") Koestler uses the phrase because Carroll's nonsense poem is just the sort of collage of mismatched ideas that can, in his view, give rise to creativity.

Humans don't create anything new. They assemble ideas from different contexts to make something different. Creativity is a bisociation, a "sort crossing", as opposed to analytic intelligence, which is an association, a "sort-matching".

We have to give students the raw material they need to mix and match, to explore new combinations. That is why computer science students should learn lots of different programming languages -- the more different, the better! They should study lots of different ideas, even in courses that are not their primary interest: database, operating systems, compilers, theory, AI, ... That's how we create the rich sea of possibilities from which new ideas are born.

Problems, Not Solutions

If we train them to respond to problems, what happens when the problem giver goes away? Students need to learn to find and create problems!

In his early years, Behrens feared giving students examples of what he wanted, at the risk of "limiting" their creativity to what they had seen. But examples are critical, because they, too, give students the raw material they need to create.

His approach now is to give students interesting and open problems, themes on which to work. Critique their products and ideas, frequently and openly. But don't sit by their sides while they do things. Let them explore. Sometimes we in CS tend hold students' hands too much, and the result is often to turn what is fun and creative into tedious drudgery.

I'm beginning to think that one of the insidious ingredients in students' flagging interest in CS and programming is that we have taken the intellectual challenge out of learning to program and replaced it with lots of explanation, lots of text talking about technical details. Maybe our reasons for doing so seemed on the mark at the time -- I mean, C++ and Java are pretty complex -- but the unintended side effects have been disastrous.

----

I greatly enjoyed this talk. One other good thing came out of the evening: after 13 years working on the same campus, I finally met Roy, and we had a nice chat about some ideas at the intersection of our interests. This won't be the last time we cross paths this year; I hope to present a paper at his conference Camouflage: Art, Science and Popular Culture conference, on the topic of steganography.

I have an interest in writing, both in general as a means for communication and in particular as it relates to the process of programming. So I headed over to the Earth Science department yesterday for a talk on popular science writing called "Words, Maps, Rocks: One Geologist's Path". The speaker was Marcia Bjornerud of Lawrence University, who recently published the popular geology book Reading the Rocks: The Autobiography of the Earth. The Earth Science faculty is using Reading the Rocks as reader in one of their courses, and they asked Dr. Bjornerud to speak on how she came to be a geologist and a popularizer of science.

Bjornerud took a roundabout way into science. As a child, she had no desire to be a scientist. Her first loves were words and maps. She loved the history of words, tracing the etymology of cool words back to their origin in European languages, then Latin or Greek, and ultimately back to the source of their roots. The history of a word was like a map through time, and the word itself was this rich structure of now and then. She also loved real maps and delighted in the political, geographical, and temporal markings that populated them. Bjornerud told an engaging story about a day in grade school when snow created a vacation day. She remembers studying the time zones on the map and learning that at least two places had no official time zone: Antarctica and Svalborg, Norway.

These reminiscences probably strike a chord in many scientists. I know that I have spent many hours poring over maps, just looking at cities and open spaces and geopolitical divisions, populations and latitudes and relative sizes. I remember passing time in an undergraduate marketing class by studying a large wall map of the US and first realizing just how much bigger Iowa (a state I had never visited but would one day call home) was than my home state of Indiana (the smallest state west of the Appalachian Mountains!) I especially love looking at maps of the same place over time, say, a map of the US in 1500, 1650, 1750, 1800, and so on. Cities grow and die; population moves inexorably into the available space, occasionally slowing at natural impediments but eventually triumphing. And words -- well, words were why I was at this talk in the first place.

Bjornerud loved math in high school and took physics at the suggestion of friends who pointed out that the calculus had been invented in large part in order to create modern physics. She loved the math but hated the physics course; it was taught by someone with no training in the area who acknowledged his own inability to teach the course well.

It wasn't until she took an introductory college geology course that science clicked for her. At first she was drawn to the words: esker, alluvium, pahoehoe, ... But soon she felt drawn to what the words name. Those concepts were interesting in their own right, and told their own story of the earth. She was hooked.

We scientists can often relate to this story. It may apply to us; some of us were drawn to scientific ideas young. But we certainly see it in our friends and family members and people we meet. They are interested in nature, in how the world works, but they "don't like science". Why? Where do our schools go wrong? Where do we as scientists go wrong? The schools are a big issue, but I will claim that we as scientists contribute to the problem by not doing a good job at all of communicating to the public why we are in science. We don't share the thrill of doing science.

A few years ago, Bjornerud decided to devote some of her professional energy to systematic public outreach, from teaching Elderhostel classes to working with grade schoolers, from writing short essays for consumption by the lay public to her book, which tells the story of the earth through its geological record.

To write for the public, scientists usually have to choose a plot device to make technical ideas accessible to non-scientists. (We agile software developers might think of this as the much-maligned metaphor from XP.)

Bjornerud used two themes to organize her book. The central theme is "rocks as text", reading rocks like manuscripts to reveal the hidden history of the earth. More specifically, she treats a rock as a palimpsest, a parchment on which a text was written and then scraped off, to be written on again. What a wonderful literary metaphor! It can captivate readers in a day when the intrigue of forensic science permeates popular culture.

Her second theme, polarities, aims more at the micro-structure of her presentation. She had as an ulterior motive, to challenge the modern tendency to see dichotomy everywhere. The world is really a tangled mix of competing concepts in tension. Among the polarities Bjornerud explores are innovation versus conservation (sound familiar?) and strength versus weakness.

Related to this motive is a desire -- a need -- to instill in the media and the public at larger an appetite for subtlety. People need to know that they can and sometimes must hold two competing ideas in their minds simultaneously. Science is a halting journey toward always-tentative conclusions.

These themes transfer well to the world of software. The tension between competing forces is a central theme driving the literature of software patterns. Focusing on a dichotomy usually leads to a sub-optimal program; a pattern that resolves the dichotomy can improve it. And the notion of "program as text" is a recurring idea. I've written occasionally about the value in having students read programs as they learn to write them, and I'm certainly not the first person to suggest this. For example, Owen Astrachan once wrote quite a bit on apprenticeship learning through reading master code (see, for example, this SIGCSE paper). Recently, Grady Booch blogged On Writing, in which he suggested "a technical course in selected readings of software source code".

Bjornerud talked a bit about the process of writing, revising, finding a publisher, and marketing a book. Only one idea stood out for me here... Her publisher proposed a book cover that used a photo of the Grand Canyon. But Bjornerud didn't want Grand Canyon on her cover; the Grand Canyon is a visual cliche, particularly in the world of rocks. And a visual cliche detracts from the wonder of doing geology; readers tune out when they see yet another picture of the Canyon. We are all taught to avoid linguistic cliches like the plague, but how many of us think about cliches in our other media? This seemed like an important insight.

Which programs are the cliches of software education? "Hello, World", certainly, but it is so cliche that it has crossed over into the realm of essential kitsch. Even folks pitching über-modern Ruby show us puts "Hello, World." Bank account. Sigh, but it's so convenient; I used it today in a lecture on closures in Scheme. In the intro Java world, Ball World is the new cliche. These trite examples provide a comfortable way to share a new idea, but they also risk losing readers whose minds switch off when they see yet another boring example they've seen before.

In the question-and-answer session that followed the talk, Bjornerud offered some partial explanations for where we go wrong teaching science in school. Many of us start with the premise that science is inherently interesting, so what's the problem?

• Many science teachers don't like or even know science. They have never really done science and felt its beauty in their bones.

  This is one reason that, all other things being equal, an active scholar in a discipline will make a better teacher than someone else. It's also one of the reasons I favor schools of education that require majors in the content area to be taught (Michigan State) or that at least teach the science education program out of the content discipline's college (math and science education at UNI).

• We tend explain the magic away in a pedantic way. We should let students discover ideas! If we tell students "this is all there is to it", we hide the beauty we ourselves see.

• Bjornerud stressed the need for us to help students make a personal connection between science and their lives. She even admitted that we might help our students make a spiritual connection to science.

• Finally, she suggested that we consider the "aesthetic" of our classrooms. A science room should be a good place to be, a fun place to engage ideas. I think we can take this one step further, to the aesthetic of our instructional materials -- our code, our lecture notes, our handouts and slides.

The thought I had as I left the lecture is that too often we don't teach science; we teach about science. At that point, science becomes a list of facts and names, not the ideas that underlie them. (We can probably say the same thing about history and literature in school, too.)

Finally, we talked a bit about learning. Can children learn about science? Certainly! Children learn by repetition, by seeing ideas over and over again at increasing degrees of subtlety as their cognitive maturity and knowledge level grow. Alan Kay has often said the same thing about children and language. He uses this idea as a motivation for a programming language like Smalltalk, which enables the learner to work in the same language as masters and grow in understanding while unfolding more of the language as she goes. His groups work on eToys seeks to extend the analogy to even younger children.

Most college students and professionals learn in this way, too. See the Spiral pedagogical pattern for an example of this idea. Bjornerud tentatively offered that any topic -- even string theory!?, can be learned at almost any level. There may be some limits to what we can teach young children, and even college students, based on their level of cognitive development, their ability to handle abstractions. But for most topics most of the time -- and certainly for the basic ideas of science and math -- we can introduce even children to the topic in a way they can appreciate. We just have to find the right way to pitch the idea.

This reminds me, too, of Owen Astrachan and his work on apprenticeship mentioned above. Owen has since backed off a bit from his claim that students should read master code, but not from the idea of reading code itself. When he tried his apprenticeship through reading master code, he found that students generally didn't "get it". The problem was that they didn't yet have the tools to appreciate the code's structures, its conventions and its exceptions, its patterns. They need to read code that is closer to their own level of programming. Students need to grow into an appreciation of master code.

Talks like this end up touching on many disparate issues. But a common thread runs through Bjornerud's message. Science is exciting, and we scientists have a responsibility to share this with the world. We must do so in how we teach our students, and in how we teach the teachers of our children. We must do so by writing for the public, engaging current issues and helping the citizenry to understand how science and technology are changing the world in which we live, and by helping others who write for the public to appreciate the subtleties of science and to share the same through their writing.

I concur. But it's a tall order for a busy scientist and academic. We have to choose to make time to meet this responsibility, or we won't. For me, one of my primary distractions is my own curiosity -- that which makes us a scientist in the first place drives us to push farther and deeper, to devote our energies to the science and not to the popularizing of it. Perhaps we are doomed to the G. H. Hardy's conclusion in his wonderful yet sad A Mathematician's Apology: Only after a great mind has outlived its ability to contribute to the state of our collective knowledge can -- should? will? -- it turn to explaining. (If you haven't read this book, do so soon! It's a quick read, small and compact, and it really is both wonderful and sad.)

But I do not think we are so doomed. Good scientists can do both. It's a matter of priorities and choice.

And, as in all things, writing matters. Writing well can succeed where other writing fails.

Back in March, I was contacted by my local paper for an article on local bloggers. That was, I think, the first time that someone outside my expected audience had contacted me about my blog.

Last week, I was contacted by a gentleman named Alex Gofman, who is CTO for Moskowitz Jacobs Inc. and is writing a book on the marketing techniques of his company's founder, Howard Moskowitz. If you have been reading this blog for long, you may remember a nearly year-old article I wrote entitled What Does the iPod have in Common with Prego Spaghetti Sauce?, in which I discussed some ideas on design, style, and creativity. My thoughts there were launched by articles I'd read from Paul Graham and Malcolm Gladwell. The Gladwell piece had quoted Moskowitz, and I quoted Gladwell quoting Moskowitz.

Mr. Gofman apparently had googled on Moskowitz's name and come across my blog as a result. He was intrigued by the connections I made between the technique used to revive Prego and the design ideas of Steve Jobs, Paul Graham, agile software methods, and Art and Fear. He contacted me by e-mail to see if I was willing to chat with him at greater depth on these ideas, and we had a nice 45-minute conversation this morning.

It was an interesting experience talking about an essay I wrote a year ago. First of all, I had to go back and read the piece myself. The ideas I wrote about then have been internalized, but I couldn't remember anything particular I'd said then. Then, during the interview, Mr. Gofman asked me about an earlier blog entry I'd written on the rooster story from Art and Fear, and I had to scroll down to remember that piece!

Our conversation explored the edges of my thoughts, where one can find seeming inconsistencies. For example, the artist in the rooster story did many iterations but showed only his final product. That differs from what Graham and XP suggest; is it an improvement or a step backward? Can a great designer like Jobs create a new and masterful design out of whole cloth, or does he need to go through a phase of generating prototyping to develop the idea?

In the years since the Prego experience reported by Gladwell, Moskowitz has apparently gone away from using trained testers and toward many iterations with real folks. He still believes strongly in generating many ideas -- 50, not 5 -- as a means to explore the search space of possible products. Mr. Gofman referred to their technique as "adaptive experimentation". In spirit, it still sounds a lot like what XP and other agile methods encourages.

I am reluctant to say that something can't happen. I can imagine a visionary in the mold of Jobs whose sense of style, taste, and the market enable him to see new ideas for products that help people to feel desires they didn't know they had. (And not in the superficial impulse sense that folks associate with modern marketing.) But I wouldn't want to stake my future or my company on me or most anyone I know being able to do that.

The advantage of the agile methods, of the techniques promoted in Art and Fear, is that they give mere mortals such as me a chance to create good products. Small steps, continuous feedback from the user, and constant refactoring make it possible for me to try working software out and learn from my customers what they really want. I may not be able to conceive the iPod, but I can try 45 kinds of sauce to see which one strikes the subconscious fancy of a spaghetti eater.

This approach to creating has at least two other benefits. First, it allows me to get better at what I do. Through practice, I hone my skills and learn my tools. Though sheer dent of repetition and coming into contact with many, many creations, I develop a sense of what is good, good enough, and bad. Second, just by volume I increase my chances of creating a masterpiece every now and then. No one may have seen all of my scratch work, but you can be sure that I will show off my occasional masterpiece. (I'm still waiting to create one...)

We should keep in mind that even visionary designers like Jobs fail, too -- whether by creating a product ahead of its time, market- or technology-wise too soon, or by simply being wrong. They key to a guy like Jobs is that he keeps coming back, having learned from his experience and trying again.

I see this mentality as essential to my work as a programmer, as a teacher, and now as an administrator. My best bet is to try many things, trust my "customer" (whether user, student, or faculty colleague) enough to let them see my work, and try to get better as I go on.

In part as a result of our conversation this morning, Mr. Gofman -- who is a software developer trained as a computer engineer -- decided to proposing adding a chapter to his book dealing with software development as a domain for adaptive experimentation. I learned that he is an XP aficionado who understands it well enough to know that it has limits. This chapter could be an interesting short work on agile methods from a different angle. I look forward to seeing what may result.

As Mr. Gofman and I chatted this morning, I kept thinking about how fear and creativity had come up a few times at OOPSLA this year, for example, here and here. But I didn't have a good enough reason to tell him, "You should read every article on my blog." :-) In any case, I wish him luck. If you happen to read the book, be on the look out for a quote from yours truly.

I haven't written about running for a while. Some of my friends were getting worried... Had my TC Marathon experience soured me? Not at all. But I haven't been training for a race, or running with any particular purpose in mind, so there hasn't been much to say. I've just been running. The first few weeks after any marathon are filled with the body recovering, so some days feel great and others feel just OK. That pretty much sums up my weeks since Twin Cities.

While in San Diego for OOPSLA, I wasn't able to do any fancy-dancy running, as the friend who was going to be my running guide was sick. (Get better, Kris!) So I took advantage of our location just south of Fashion Valley Shopping Center to jog up to Friars Road and use it as my main artery. One day, I ran to the campus of University of San Diego; a couple of other times, I ran to Jack Murphy Stadium, and once I ran out past Sea World and over the beachfront bridge that spans the San Diego River. Friars Road worked about as well as any major urban street could for morning runs. For the week, I put in well over 30 miles; not bad for such a busy conference week... (There is hidden advantage of attending conferences on the west coast -- I just keep rising on Iowa time!)

I've now done a couple of 12-milers and 14-miler, so my distance is doing fine. My long speed is coming back slowly, and I've comfortably managed a couple of long routes at 8.5 minutes/mile pace.

This morning was my finest fast run yet. I ran one of my standard short routes, 5.5 miles, with the intention of getting done and getting to my office earlier to grade and prep class. And get done fast I did -- in 40:52, more than 15 seconds faster than I've ever run this route. My legs were a bit sore this morning, but it was the kind of soreness that I look forward to!

Now I am getting excited about running the Snow Shuffle 5K on December 10. It's tough to PR races in the cold of December, and there is always the chance of snow or ice or fierce wind. So I won't plan for anything other than running as fast as the conditions allow. But the thought of racing, however short, sounds good again.

I have now published the last of my entries intended to describe the goings-on at OOPSLA 2005. As you can see from both the number and the length of entries I wrote, the conference provided a lot of worthwhile events and stimulated a fair amount of thinking. Given the number of entries I wrote, and the fact that I wrote about single days over several different entries and perhaps several weeks, I thought that some readers might appreciate a better-organized index into my notes. Here it is.

Of course, many other folks have blogged on the OOPSLA'05 experience, and my own notes are necessarily limited by my ability to be in only one place at a time and my own limited insight. I suggest that you read far and wide to get a more complete picture. First stop is the OOPSLA 2005 wiki. Follow the link to "Blogs following OOPSLA" and the conference broadsheet, the Post-Obvious Double Dispatch. In particular, be sure to check out Brian Foote's excellent color commentary, especially his insightful take on the software devolution in evidence at this year's conference.

Now, for the index:

Day 1

• The Morning of Extravagaria
• Writing Exercises at Extravagaria

Day 2

• Morning at The Educators' Symposium
• Ward Cunningham on Seeking and Exploiting Simplicity
• A Panel of the Direction of CS Education

Day 3

• Robert Hass on Creativity
• Sussman on Expressing Poorly-Understood Ideas in Programs
• "Mechanistic", a follow-up to Sussman's talk based on an e-mail exchange with concert pianist James Boyk (whom Sussman quotes)

Day 4

• Mary Beth Rosson on the End of Users

Day 5

• Martin Fowler on Finding Good Design
• Grady Booch on Software Architecture Preservation

This and That

• Part 1: on grammar, Maxwell's Equations, and rants
• Part 2: the Echoes and Yoshimi panels
• Part 3: Geek Jargon
• Part 4: Inside Stories
• More on Safety and Freedom in the Extreme

I hope that this helps folks navigate my various meanderings on what was a very satisfying OOPSLA.

Finally, thanks to all of you who have sent me notes to comment on this postings. I appreciate the details you provide and the questions you ask...

Now, get ready for OOPSLA 2006.

The final item on the Educators Symposium program this year was a panel discussion on the future of computer science education. It was called Are We Doomed? Reframing the Discussion, in partial gest following last SIGCSE's panel debate Resolved: "Objects Early" Has Failed. After that session, Owen Astrachan commented, "We're doomed." What did he mean by this? Despite our own declarations that this is The Age of Information and that computer science is a fundamental discipline for helping the world to navigate and use the massive amount of information now being collected, we still teach CS courses in essentially the same way we always have. We still use toy examples in toy domains that don't really matter to anyone, least of all of students. We still teach our introductory courses as 100% old-style programming, with barely a nod to users, let alone to the fact that sophisticated consumers of computing grow increasingly independent of us and our inward focus.

This summer, Owen said it this way:

We have the human genome project, we have Google, we have social networks, we have contributions to many disciplines, and our own discipline, but we argue amongst ourselves about whether emacs is better than vi, Eclipse better than IDEA, C++ better than Java or Scheme, or what objects-first really means.

I'm sorry, but if we don't change what we talk about amongst ourselves, we are doomed to a niche market while the biologists, the economists, the political scientists, etc., start teaching there own computational/modeling/programming/informatics courses. Nearly everyone turns to math for calculus, nearly everyone turns to math/stats for statistics. These are nearly universally acknowledged as basic and foundational for *lots* of disciplines. In the age of information nearly no discipline at a large scale requires computer science, certainly not programming as we teach it.

Owen isn't as pessimistic as the provocative "We're doomed" sounds; he simply wants to cause us to think about this sea change and begin to make a change ourselves.

I decided that this would make a great closing for my second Educators Symposium. Last year, my first symposium opened with Alan Kay challenging us all to set a higher bar for ourselves -- in computer science, and in computer science education. This year, my second symposium would close with a challenge to reinvent what we do as a discipline.

As in so many things, the panel did not turn out quite the way I had planned. First of all, Owen wasn't able to be at OOPSLA after all, so we were without our intellectual driving force. Then, when the panel went live, discussion on the panel went in a different direction than I had planned. But it had its good points nonetheless. The panel consisted of Robert Biddle, Alistair Cockburn, Brian Marick, and Alan O'Callaghan. I owe special thanks to Alistair and Alan, who joined us on relatively short notice.

As moderator, I had hoped to pen a wonderfully humorous introduction for for each of the panelists, to loosen things up before we dropped the gloves and got serious about changing the face of computer science. Perhaps I should have commissioned a master to ghostwrite, for in my own merely mortal hands my dream went unfulfilled. I did have a couple of good lines to use. I planned to introduce Robert as the post-modern conscience of the Educators Symposium, maybe with a visual bow to one of his previous Onward! presentations. For Brian, my tag line was to be "the panelist most likely to quote Heidegger -- and make you love him anyway". But I came up short for Alistair and Alan. Alistair's paper on software development as cooperative game playing was one possible source of inspiration. For Alan, all I could think was, "This guy has a higher depth/words ratio than most everyone I know". In the end, I played it straight and we got down to business rather quickly.

I won't try to report the whole panel discussion, as I got sucked into it and didn't take elaborate notes. In general, rather than focusing on how CS is being reinvented and how CS education ought to be reinvented, it took a turn toward metaphors for CS education. I will describe what was for me the highlight of the session and then add a couple of key points I remember.

The highlight for me was Robert's presentation, titled "Deprogramming Programming". It drew heavily on the themes that he and James Noble have been pitching at recent Onward! performances, in particular that much of what we take as accepted wisdom in software development these days is created by us and is, all too often, just wrong.

He started with a quote from Rem Koolhaus and Bruce Mau's "S, M, L, XL":

Sous le pavé, la plage.
(Under the paving stone, the beach.)

There is something beneath what we have built as a discipline. We do not program only our computers... We've programmed ourselves, in many wrong ways, and it's time to undo the program.

The idea that there is a software crisis is a fraud. There isn't one now, and there wasn't one when the term 'software engineering' was coined and became a seemingly unavoidable part of our collective psyche. Robert pointed out that in Greek mythology Narcissus fell in love not with himself but with his reflection. He believes that the field of software engineering has done the same, fallen in love with an image of itself that it has created. We in CS education are often guilty of the same offense.

Robert then boldly asserted that he loves his job as a teacher of computing and software development. If we look under the pavement, we will see that we developed a lot of useful, effective techniques for teaching students to build software: study groups, role play, and especially case studios and studios. I have written before about my own strong belief in the value of case studios and software studios, so at this point I nearly applauded.

Finally:

The ultimate goal of computer science is the program.

This quote is in someways antithetical to the idea Owen and I were basing the panel on (which is one reason I wanted Robert to be on the panel!), but it also captures what many folks believe about computing. I am one of them.

That certainly doesn't do justice to the stark imagery and text that constituted Robert's slides, nor to the distinctive verbal oratory that Robert delivers. But it does capture some of the ideas that stuck with me.

The rest of the panel presentations were good, and the discussion afterward ranged far and wide, with a recurring them of how we might adopt a different model for teaching software development. Here are a few points that stood out:

• Brian offered two of ideas of interest: demonstration a lá the famed on-line demo of using Ruby on Rails to build a blog engine fifteen minutes, and education patterned on that his wife received and dishes out as a doctor of veterinary medicine.

• Alan said that we in CS tend to teach the anatomy of a language, not how to use a language. He and I have discussed this idea before, and we both believe that patterns -- elementary or otherwise -- are a key to changing this tendency.

• Dave West chimed in from the audience with a new statement of computer science's effect on the world reminiscent of his morning presentation: "We are redefining the world in which all of us work and live."

• Two ideas that should be a bigger part of how we teach software development are a focus on useful things and study of existing work. Various people have been using these ideas in various forms for a while now, and we have uncovered some of the problems hidden behind their promise. For example, students aren't often ready to read programs that are *too* good very quickly; they simply don't appreciate their goodness until they have developed a better sense of taste. But if we framed more of our teaching efforts around these ideas and worked to compensate for their shortcomings, we would probably be better off than doing The Same Old Thing.

All in all, the panel did not go where I had intended for it to go. Of course, Big Design Up Front can be that way. Sometimes you have to take into account what your stakeholders want. In my case, the stakeholders were the panelists and the audience, with the audience playing the role of pseudo-customer. Judging from the symposium evaluations, many folks enjoyed the panel, so maybe it worked out all right after all.

Of course, what I had hoped for the panel was to challenge folks in the audience to feel uneasy about the direction of the discipline, to dare to think Big Thoughts about our discipline. I don't think we accomplished that. There will be more opportunities in the future.

As PragDave recently wrote, the Ruby Extensions Project contains a "absolutely wonderful hack". This hack brought back memories and also reminded me of a similar but more ambitious project going on in the Ruby world.

First of all, here's the hack... One of Ruby's nice features is its collections' internal iterators. Instead of writing a for-loop to process every item in a collection, you send the collection a map message with a one-argument block as its argument. PragDave's example is to convert all the strings in an array uppercase, and the standard Ruby code is

names.map { |name| name.upcase }

The map method applies the block -- effectively a nameless method -- to every item in names.

This is a very nice feature, but after you program in Ruby you want more... Isn't writing that block more work than I should have to do? Why can't I just pass upcase, which is a one-argument method, as the argument to map? Because upcase isn't a method or a procedure; it's a symbol that names a method.

As PragDave reports, the Ruby Extensions hack adds a method to the Symbol class that allows Symbols to be coerced to a procedure object at run-time. The result is that we can now write the following:

names.map(&:upcase)

That's more succinct and avoids the need to create a new procedure object on the fly.

Now the memory... I distinctly remember the afternoon I learned the same hack in Smalltalk, back in the summer of 1988. You see, Smalltalk's collections also offer an array of internal iterators that eliminates the need to write most for-loops, and these iterators take blocks as arguments.

I was just learning Smalltalk and loved this idea -- it was my first exposure to object-oriented programming and the power of blocks, which are like functional programming's higher-order procedures. I was working on some code to sort a collection. In Smalltalk, collections also respond to a sort: message, whose argument is a two-argument block for comparing the values. So, to sort a collection of strings in ascending order, I could write:

names sort: [ x y | x < y ]

But soon I wanted more... Why can't I just pass < to sort:? The same reason I can't do it in Ruby: < isn't a block or a method; it is a symbol that names a method.

While figuring this out, I learned how sort: works. It turns around and sends the block a value:value: message with pairs of values from the collection as the two arguments. Hmm, what if a Symbol could respond to value:value: and do the right thing? I added a one-line method to the Symbol class, and they could:

value: anObject value: otherObject
      ^anObject perform: self with: otherObject

(perform: behaves something like Scheme's eval procedure.)

And now I could write the wonderfully compact

names sort: <

I soon added the one-argument form to Symbol, too, and began to write new code with abandon.

I felt pretty smug at the time, for having created something so beautiful. But I soon learned that I had merely rediscovered a hack that every Smalltalk programmer either reinvents or sees in someone else's code. That didn't diminish the beauty of my idea, but it did extinguish my smugness.

It turns out that this new hack is not only more compact and more convenient to write, but it runs faster than the block alternative, too. The callback on the symbol doesn't require the creation of a block on the fly, which requires memory allocation and the whole bit.

Finally, for the more ambitious project... This cool hack points out that Ruby and Smalltalk method names are symbols, and without some coercion they are not evaluated to their method values in ordinary use. What if messages were first-order objects in these languages? If so, then I can writing message sends that take other messages as arguments, thus creating higher-order messages. If you are interested in this idea, check out Nat Pryce's recent efforts to add higher-order messaging to Ruby, if you haven't already seen it. Nat gives a link to the paper that laid the foundation for this idea and steps you through the value of higher-order messages and their implementation in Ruby. It's another absolutely wonderful hack.

Two of Paul Graham's latest essays, Ideas for Startups and What I Did This Summer, echo ideas about simplicity, exploration, and conventional wisdom that Ward Cunningham talked about in his Educators' Symposium keynote address. Of course, Graham speaks in the context of launching a start-up company, but I don't think he sees all that much difference between that and other forms of exploration and creation.

Ideas for Startups focuses first on a problem that many people face when trying to come up with a Big Idea: they try to come up with a Big Idea. Instead, Graham suggests asking a question...

Treating a startup idea as a question changes what you're looking for. If an idea is a blueprint, it has to be right. But if it's a question, it can be wrong, so long as it's wrong in a way that leads to more ideas.

Humility. Simplicity. Learn something along the way. This is just the message that Ward shared.

Later, he speaks of how to "do" simplicity...

Simplicity takes effort -- genius, even. ... It seems that, for the average engineer, more options just means more rope to hang yourself.

In this regard, Ward offers more hope to the rest of us. Generating a truly great something may require genius; maybe not. But in any case, ordinary people can act in a way that biases their own choices toward simplicity and humility, and in doing so learn a lot and create good programs (or whatever). That's what things like CRC cards, patterns, and XP are all about. I know a lot of people think that XP requires Superhero programmers to succeed, but I know lots of ordinary folks who benefit from the agile mindset. Take small steps, make simple choices where possible, and get better as you go.

I am not sure whether of how pessimistic Graham really is here about achieving simplicity, but his writing often leaves us thinking he is. But I prefer to read his stuff as "Yeah, I can do that. How can I do that?" and take good lessons from what he writes.

Then, in "What I Did This Summer", Graham relates his first experience with the Summer Founders Program, bankrolling a bunch of bright, high-energy, ambitious your developers. Some of the lessons his proteges learned this summer are examples of what Ward told us. For example, on learning by doing:

Another group was worried when they realized they had to rewrite their software from scratch. I told them it would be a bad sign if they didn't. The main function of your initial version is to be rewritten.

This is an old saw, one I'm surprised that the SFP needed to learn. Then again, we often know something intellectually but, until we experience it, it's not our own yet.

But I really liked the paragraphs that came next:

That's why we advise groups to ignore issues like scalability, internationalization, and heavy-duty security at first. I can imagine an advocate of "best practices" saying these ought to be considered from the start. And he'd be right, except that they interfere with the primary function of software in a startup: to be a vehicle for experimenting with its own design. Having to retrofit internationalization or scalability is a pain, certainly. The only bigger pain is not needing to, because your initial version was too big and rigid to evolve into something users wanted.

I suspect this is another reason startups beat big companies. Startups can be irresponsible and release version 1s that are light enough to evolve. In big companies, all the pressure is in the direction of over-engineering.

Ward spoke with great feeling about being willing to settle for the incomplete, about ignoring some things you probably shouldn't ignore, about disobeying conventional wisdom -- all in the service of keeping things simple and being able to see patterns and ideas that are obscured by the rules. We are conditioned to think of these behaviors as irresponsible, but they may in fact point us in the most likely direction of success.

----

I also found one really neat idea to think about from reading these papers that is independent of Ward's Cunningham. Graham was talking about doodling and what the intellectual equivalent is, because doodling is such a productive way for visual artists to let their minds wonder. Technical innovators need to let their minds wander so that they can stumble upon newly synthesized ideas, where a common frame of reference is applied to some inappropriate data. This can be the source of analogies that help us to see newly.

Out of this discussion, his programmer's mind created a programming analogy:

That's what a metaphor is: a function applied to an argument of the wrong type.

What a neat idea, both as a general characterization of metaphor and also as a potential source of ideas for programming languages. What might a program gain from the ability to reason about a function applied to invalid arguments? On its face, that's an almost meaningless question, but that's part of Graham's -- and Ward's -- point. What may come from such a thought? I want to think more.

I don't know that I have any more time than Graham to spend on this particular daydream...

The keynote address for this year's Educators' Symposium was given by Ward Cunningham, one of the software folks I admire most. Of course, he's admired by many folks, including not surprisingly by the folks who organized the Wiki Symposium launched by and collocated with OOPSLA this year. As a result, Ward's keynote to our group had to be moved from its traditional first slot of the day to the slot immediately after lunch. This gave the keynote a different feel, because we all had a morning's worth of activities in which to hear Ward's words. (You can read a summary of Ward's Wiki Symposium keynote, titled "The Crucible of Creativity".)

I introduced Ward by telling the audience how I first encountered his work. At AAAI 1995 in Montreal, I was discussing some of my ideas on teaching elementary patterns with a colleague from Wales. He said, "I have a book for you to review..." You see, he was one of the editors of the journal Expert Systems, and he had received a book for review that he didn't know what to do with. It was about software patterns, and he figured that I'd be an okay reviewer. He was probably encouraged to think this by the fact that none of his other AI friends seemed to be interested.

The book was Pattern Languages of Program Design, and it changed my life. I had never been exposed to the nascent software patterns community, and this book introduced me to a lot of ideas and, ultimately, people who have played an important role in my academic work since.

One of the papers in PLoPD-1 affected me immediately. It was about the CHECKS pattern language, and it was written by Ward Cunningham. These patterns were so simple, so obvious, yet as I read them I learned something about maintaining the integrity of the data in my programs. As I looked for more of Ward's work, I soon learned that what attracted me to CHECKS was a hallmark of Ward's: the ability to recognize simple ideas that offered unexpected depth and to explore that depth, patiently and humbly. So many of Ward's contributions to standard practice have been the result of a similar process: CRC cards, patterns, wiki, extreme programming, test-first design, and FIT among them.

I asked Ward to keynote the Educators Symposium because I admired his work but because I hoped that he could teach us educators -- especially me -- a little bit of his secret gift. Maybe I could nurture the gift in myself, and maybe even pass on something to my students.

Ward opened his talk with a reminiscence, too. As an electrical engineering major in college, he learned about Maxwell's equations from a Professor Simpson. The professor taught the equations with passion, and he expected his students to appreciate their beauty. Much of their beauty lay in their simplicity, in how that brought so many important facets together into such a small number of straightforward equations. Professor Simpson also loved the work of Richard Feynman, who himself appreciated simplicity and wrote with humanity about what he learned.

One of Ward's first slides was The Big Slide, the take-home point of his talk. He characterized his way of working as:

Immerse yourself in a pool of ideas. Come to know them. Make them your own. Then look for some humble idea lying around, something that we all understand or might. Play with this idea to see whether it gives rise to something unexpected, some new ability that changes how we see or work with the pool of familiar ideas you are swimming in.

I have experienced the dangers inherent in looking for a breakthrough idea in the usual ways. When we look for Big Ideas, too often we look for Big Ideas. But they are hard to find. Maybe we can't recognize them from our current vantage point; maybe they are out of scale with the ideas we have right now.

Ward pointed out another danger: Too often, we look for complete ideas when a simple but incomplete idea will be useful enough. (Sounds like You Aren't Gonna Need It!)

Sometimes, we reach a useful destination by ignoring things we aren't supposed to ignore. Don't worry about all the things you are supposed to do, like taking your idea through to its logical conclusion right away, or polishing it up so that everyone can see how smart you are. Keep the ideas simple, and develop just what you need to move forward.

Ward pointed out that one thing we educators do is the antithesis of his approach: the project due date. It forces students to "get done", to polish up the "final version", and to miss opportunities to explore. This is one of the good things behind longer-term projects and undergraduate research -- they allow students more time to explore before packaging everything up in a neat little box.

How can we honor the simple in what we do? How can we develop patience? How can we develop the ability to recognize the simple idea that offers more?

Ward mentioned Kary Mullis's Dancing Naked in the Mind Field as a nice description of the mindset that he tries to cultivate. (You may recall my discussion of Mullis's book last year.) Mullis was passionate, and he had an immediate drive to solve a problem that no one thought mattered much. When he showed his idea to his colleagues, they all said, "Yeah, that'd work, but so what?". So Mullis gave in to the prevailing view and put his idea on the shelf for a few months. But he couldn't shake the thought that his simple little not-much of an idea could lead to big things, and eventually he returned to the idea and tinkered a little more... and won a Nobel Prize.

Extreme Programming grew out of the humble practices of programmers who were trying to learn how to work in the brave new image of Smalltalk. Ward is happy that P creates a work environment that is safe for the kind of exploration he advocates. You explore. When you learn something, you refactor. XP says to do the simplest thing that could possibly work, because you aren't gonna need it.

Many people have misunderstood this advice to mean do something simplistic, something stupid. But it really means that you don't have to wait until you understand everything before you do anything. You can do useful work by taking small steps. These principles encourage programmers to seriously consider just what is the simplest thing that could possibly work. If you don't understand everything about your domain and your task, at least you can do this simplest thing now, to move forward. When you learn more later, you won't have over-invested in ideas you have to undo. But you will have been making progress in the meantime.

(I don't think that Ward actually said all of these words. They are my reconstruction of what he taught me during his talk. If I have misrepresented his ideas in any way, the fault is mine.)

Ward recalled first getting Smalltalk, which he viewed as a "sketchpad for the thinking person to write spike solutions". Have an idea? Try to program it! Everything you need or could want to change is there before you, written in the same language you are using. He and Kent realized that they now had a powerful machine and that they should "program in a powerful way". Whenever in the midst of programming they slowed down, he would ask Kent, "What is the simplest thing that could possibly work?", and they would do that. It got them over the hump, let them regain their power and keep on learning.

This practice specializes his Big Slide from above to the task of programming:

Remember: You can't do it all at once. Ride small steps forward.

This approach to programming did not always follow the most efficient path to a solution, but it always made progress -- and that's more than they could say by trying to stay on the perfect path. The surprise was that the simple thing usually turned out to be all they needed.

Ward then outlined a few more tips for nurturing simple ideas and practices:

Practice that which is hard.

... rather than avoiding it. Do it every day, not just once. An example from software development is schema evolution. It's too hard to design perfect schema up front, so design them all the time.

Hang around after the fact.

After other people have explored an area heavily and the conventional wisdom is that all of the interesting stuff has been done, hang around. Tread in well-worn tracks, looking for opportunities to make easier what is hard. He felt that his work on objects was a good example.

Connect with lower level abstractions.

That's the beauty of Smalltalk -- so many levels of abstraction, all written in the same language, all connected in a common way.

Seek a compact expression.

In the design of programming languages, we often resist math's greatest strength -- the ability to create compact expressions -- in favor of uniformity. Smalltalk is two to four times more compact than Java, and Ward likes that -- yet he knows that it could be more compact. What would Smalltalk with fewer tokens feel like?

Reverse prevailing wisdom.

Think the opposite of what everyone says is the right way, or the only way. You may not completely reverse how you do what you do, but you will be able to think different thoughts. (Deconstruction reaches the technical world!)

From the audience, Joe Bergin pointed out his personal favorite variant of this wisdom (which, I think, ironically turns Ward's advice back on itself): Take a good idea and do it to the hilt. This is, of course, how Kent Beck initially described XP -- "Turn the knobs up to 10."

Simplicity is not universal but personal, because it builds upon a person's own pool of familiar ideas. For example, if you don't know mathematics, then you won't be able to avail yourself of the simplicities it offers. (Or want, or know to want to.)

At this point, Ward ended his formal talk and spent almost an hour demonstrating some of these ideas in the testbed of his current hobby project, the building of simple computers to drive an equally simple little CRT. I can't do justice to all he showed us during this phase of his keynote, but it was remarkable... He created his own assembly language and then built a little simulator for it in Java. He created macros. He played with simple patterns on the screen, and simple patterns in the wiring of his little computer board. He hasn't done anything to completion -- his language and simulator enable him to do only what he has done so far. But that has been good enough to learn some neat ideas about the machines themselves and about the programs he's written.

While I'm not sure anything concrete came out of this portion of his talk, I could see Ward's joy for exploration and his fondness for simple questions and just-good-enough solutions while playing.

We probably should all have paid close attention to what Ward was doing because, if the recent past has taught us anything, it is that in five years we will all be doing what Ward is playing with today.

I'm finally breaking away from the work that stacked up while I was at OOPSLA and so took the luxury of catching up on some blog reading. Some of that reading turned to OOPSLA itself!

Thanks to Brian Foote for his compliment on my OOSPLA posts. I'd never thought to characterize my conference reporting style as "play by play", but Brian, as usual, turns the apt phrase. I am please to play this role. If only I can manage to be the Bob Costas of conference reporting, I'll be proud. Of course. I'll be on the look-out for solid color commentators to complement my work.

Though I'm not in his league, Martin Fowler can do my color commentary any time. Martin wrote a nice summary of OOPSLA, with much pithier summaries of several key ideas than my fuller-featured posts managed. One of the great things about blogs as a medium these days is that we all get a chance to see conferences from many different points of view, including the points of view of Big Names in the field. If you missed the conference, these reports are irreplaceable, but they also offer something special to those of us who attended -- they enrich our own experiences.

In Martin's summary, I found the pointer to Brian Foote's post mentioned above, which also contains the full text of his introduction for Martin's invited talk. Apparently, Brian himself was not allowed to deliver the address, so Ralph Johnson read it. Ralph did a nice job trimming the text down, and he delivered his lines credibly. But now you can read the unabridged version for yourself!

And now from the "Watching the Sausage Being Made" department... I can tell you that such introductions are often post-modern works of art, assembled from ideas bantered across a table crammed with pastries, coffee cups, laptop computers, power cords, and power strips. Ubiquitous internet access and Google have opened this process to the full world of pastiche. I especially enjoyed playing an ever-so-small part in James Noble's creation of his introduction to Mary Beth Rosson's talk. Here's the story.

Mary Beth chaired OOPSLA the year it was in Minneapolis. Now, Minneapolis was home to iconic American television character Mary Richards, a spunky, optimistic go-getter. Apparently Dick Gabriel riffed on the similarity between the Mary Tyler Moore character and Mary Beth's own cheerful disposition. He coached Mary Beth on how to make MTM's signature cap toss from the TV show's opening theme, figuring she could do it as she took the stage for the grand opening of the conference. I wasn't there, but from what I can gather Mary Beth never quite mastered the cap toss in the time available. It occurs to me now that I don't know if she tried the toss after all or not!

Back to OOPSLA 2005... As James contemplated out loud his introduction for Mary Beth's talk later that morning, someone suggested an inside joke to play off the Minneapolis experience. Ultimately, this lead to James wanting to incorporate the lyrics of the theme song into his intro. During the conversation, I was at my iBook, eavesdropping while checking e-mail. I quickly found the lyrics on-line and passed them on to James, who made them his own in a fine theatric reading.

I was happy just to help. And I hope Mary Beth can forgive me. :-)

I obviously enjoyed my time at OOPSLA last week and am already looking forward to OOPSLA 2007 in Portland. But conference travel -- especially a trip that lasts most of a week -- is tiring, and upon returning to the office I usually have a lot of work backed up. The trade-off is two days of hyper-activity in which so much gets done.

The day before I leave for a trip, I usually have a lot to do. Traveling to OOPSLA this year was the best case scenario. I did my last classes and meetings for the week on Thursday, and I flew to San Diego on Saturday. That left me a sweet Friday. All I had left for the week was to do all the stuff that needs to be done for class and the department before I disappeared from the office for a week: recommendation letters, department web pages, programming assignments for my course, e-mail messages to faculty and deans and various other university types. The to-do list looks insurmountable, and to the uninitiated it might seem to presage a painful day in the making. But there is no time to spare, no room for procrastination. You Just Do It. This rush to prepare to be gone can be serves as a useful impetus to get all of these things done, and now. For me, the experience is not painful, but exhilarating. Look at that to-do list shrink! That item's been on the list for weeks. Gone! Aah.

Of course, I was in the office from 7:00 AM until 7:00 PM, but I enjoyed most of it.

The second typical rush day for me is the day I travel home. I have all this time in airports and on planes, plus the energy I absorbed from intelligent, energetic colleagues at the conference. I know that I'll be back in the office in a day or two, but I am ready to do all the things that I've been jotting down as possibilities throughout the conference. I don't know anyone around me, so there are few distractions. No Internet in most places, so my attention is focused on my local work. Again a lot happens in the course of a long, tiring day, but the result satisfies.

The day traveling to the conference is not typically a good day for a dash. First, I'm excited about the conference, not about getting things done. Second, I tend to be tired from the dash the day before. Usually, my time traveling to the conference is spent reading, maybe preparing for the conference itself or maybe just relaxing with a short novel.

Why does so much get done during my sprint days? Why haven't I already done all the stuff that I have to rush through on those days? Sometimes, it is being so busy with day-to-day work that some tasks get pushed aside. Other times, it is garden-variety procrastination. Still others, it is the non-writing equivalent of writer block, just waiting for some inspiration. But inspiration comes to those already involved in the work. And, as we found during our afternoon writing exercises at the Extravagaria workshop, sprints of this sort can jolt creativity, through time pressure and loss of one's conscious mind in the details of doing the work.

I have always referred to these days as sprints, even before I was captive to running metaphors. Over at 43 Folders, they are called dashes, sometimes even mad dashes. Madness is an apt emotion, as these days often feel like hours of falling downhill. But I am getting work done.

So, I continue to like the conferences I frequent, OOPSLA, PLoP, and ChiliPLoP among them, for the life they give me. They offer an unexpected side effect in sprint days. A few sprints like this every year are good for my system.