TITLE: OOPSLA Day 2: Ward Cunningham on Seeking and Exploiting Simplicity
AUTHOR: Eugene Wallingford
DATE: November 04, 2005 8:34 AM
The keynote address for this year's
was given by
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
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
of Ward's Wiki Symposium keynote, titled "The Crucible of
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
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
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
XP 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,
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:
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.
- 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,
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