When Ward Cunningham created the very first wiki?WikiWikiWeb--he borrowed the word from the Wiki Wiki Shuttle buses at the Honolulu Airport. “⁠Wiki⁠”⁠ is the Hawaiian word for “⁠fast,⁠”⁠ but as Cunningham soon discovered, the wiki’s best virtue is not the hyperlinks that connect pages the way a shuttle connects terminals, but the wiki’s ability to foster collaboration. Every wiki is its own universe, and when people get to the edge, they can’t resist the opportunity to expand it.

Constant expansion marks Cunningham’s career, as well. In 1987 with Kent Beck, he co-authored a pioneering paper that showed how design patterns--a concept associated with architecture--could be used for object-oriented programming. Design patterns are now a key part of agile programming, and Cunningham is one of the authors of the Agile Manifesto, the movement’s founding document. Professionally, he was a principal engineer at the Tektronix Computer Research Laboratory, an architect in Microsoft’s Patterns & Practices Group, and, most recently, chief technology officer for AboutUs.org.

Last March, he became CTO of CitizenGlobal, a startup working on collaborative video content. Cunningham now divides his time between his home in Portland, Oregon, and CitizenGlobal’s headquarters in Venice Beach, California, where he is one of the people in Los Angeles preferring a bicycle to a car. Like the wiki itself, the bicycle at first seems an unlikely vehicle to traverse so much territory. But both reflect an ongoing theme in Cunningham’s work. “⁠Simplicity,⁠”⁠ he has said, “⁠is the shortest path to a solution.”

I wonder how many Honolulu visitors realize that your creation, the wiki, came from the airport bus.

That is where I learned the word, which means “⁠quick,⁠”⁠ and a wiki is a quick way to make Web pages. But now, being quick is less important than the idea of getting to a place that’s otherwise hard to reach. Through collaboration, people can make something on a wiki that they couldn’t make on their own. It’s interesting that a wiki in its simplicity is enough to engage that collaboration when so many more complicated tools can’t seem to do it.

Why do you think that is?

One thing that’s interesting about wikis is that they reverse the usual collaborative process. Usually, collaborators review and review and review--then publish. On a wiki, you first publish, then review, review, review. And that has a big impact on a system of collaboration in that it keeps the cycle time up. Things happen fast if you publish first, then review.

Where did you come up with the idea?

I had made something kind of like it in HyperCard, which showed up on my desk when my friend Kent Beck snagged a predecessor from Apple. We thought: we should use it to do something with patterns. I knew HyperCard was a new kind of paradigm in computing--and wanted to understand it. So I looked for a problem that was database-like, but didn’t fit into the typical rows and columns. What I chose was the history of engineering ideas at my company at the time, Tektronix. I started making cards for ideas, the people behind them, and the projects where those ideas applied.

This was such an expansive concept: there was no way my database was ever going to be complete, which meant that you had to talk about a person or a project without necessarily defining it. Now we can see that you eventually do get to the edge of where the hypertext takes you. You discover that there is indeed an edge there--a place that’s unknown. In Wikipedia, that’s done with red links. When you click on one, you get a note saying in effect: “⁠We don’t know--why don’t you tell us?⁠”⁠ Similarly, people would come to my desk and start browsing my database, and they couldn’t help but expand it by filling in the cards.

WikiWikiWeb is still an ongoing project, but even now, the “home page” doesn’t explain much. Its best explanation is the example it sets.

There are pages in there that do explain it, but this idea of having a front door to every website was not common at the time. The feeling was: it’s a hypertext and you should be able to enter wherever you want. I preserved that idea. People get dropped into a web of twisty little passages. When they come back up, they might say: “⁠Well I didn’t get my question answered, but I sure did learn a lot.⁠”

Are you surprised by how far the idea of a wiki has gone?

I could tell as soon as I had this working that I was on to something, that it would embody multiple languages--and when I saw Wikipedia embrace multiple languages, I thought: oh yeah, this is it. Wikipedia has really carried the wiki idea forward. When I first heard they were going to base an encyclopedia on it I thought--well that’s kind of boring, everybody already knows what an encyclopedia is. Here I’ve invented a new medium, and they’re putting old stuff on it. But of course, it’s now clear that Wikipedia isn’t just an encyclopedia. It’s really much more.

You said that things happen fast if you publish first, then review. That seems like the connecting idea for another facet of your career: agile programming.

They are two sides of the same coin: the organic growth of software is modeled, in a sense, on the organic growth of a wiki. What it comes down to is this: if you want to do something, how do you overcome the fear of not doing it right? And of course the answer is: do it often. I’ve worked with companies where we’ve spent a year or two working on a project, only to discover they can’t deliver it. So the thought was: let’s write a one-week version of the project and “⁠deliver⁠”⁠ it, then “⁠deliver⁠”⁠ a better one the following week. In other words, let’s practice delivering it. A partially completed project is still worth delivering, and that idea is similar to that of finding value in incomplete hypertext. It’s only when you’re really successful in a program that people want new versions.

Both have a really fast feedback loops.

Yeah, which means that the project stays within the attention span of the people doing the work. What usually happens is that a manager with a dozen things to do assigns one thing to each person--and so nobody works together. The better approach is to focus on a narrow part of it together. If you hand out just three things to 12 people, the message is clear: you’ve got to work together. On wiki, we get that through the notion of recent changes, which gives you an up-to-the-minute picture of what people are working on. So what you get is a lot of activity in a narrow area, with the understanding that you can move to another area when you’re ready.

Does this idea go beyond online collaboration? What about the rest of life?

I think in general that practice--with a short feedback loop--is important. Shoot a bow and arrow, and you immediately see how close to the bull’s eye you got, then readjust. When you practice piano, you listen to the sound of the music, then readjust. I know a computer scientist who plays music in a group. He says that when they hit the first chord, they already know how everybody is feeling. The sense of how they’re doing is immediate and that immediacy is a natural thing--humans are set up to do that in fractions of a second. We stretch it out because we sometimes don’t know how to communicate on shorter time scales when we’re doing traditional work. Traditional work was driven by inter-office memos typed up on carbon paper. Now we have computer networks to speed things up. Networks aren’t quite as fast as a jazz band on the first note, but they’re getting close.

Say more about this idea that wikis can help people overcome fear.

We always fear the unknown, which is why the engineers in my company wouldn’t try anything unless they had seen it work before. They didn’t want to put the project at risk by introducing too many unknowns. And yet if you want to be a powerful engineer, you need to try new things. So it helps to have a safety net where if you try something and it doesn’t go well, you can easily back out and try something else.

To actually make that work in software, we had to tear down practices that discouraged trying. In the old school, management was so afraid of mistakes that developers were encouraged to document very carefully what they were going to program, before they ever programmed it. That meant they had just one guess, and then were held to delivering on that guess. It was foolishness. The better approach is more like a pianist who practices so much that his hands play the music without him hardly thinking. We need to practice programming so that we can program without hardly thinking--so that the ideas seamlessly move from your brain to your finger tips.

How do you actually make that work among a team of developers?

First of all, you’ve got to make it safe to fail. An easy way to do that is to have a bunch of automated tests, so that if you make a mistake, the computer quickly lets you know when it’s easy to back that last change out. And we can help address the steep learning curve by asking people to program together. Paired programming is a great way to share operational knowledge among a group of professionals. You can see what works for each other.

Will the next generation of programmers, having grown up with wikis and a more fluid online environment, understand this better?

Absolutely. The transformation in some communities is already complete. The Ruby community, for example, is post-agile: there’s just an assumption that you’ll work this way. The way you architect a design is basically by shopping: you go online and see what gems are available to do the work. And when you pull one down, if you’re not happy with it, you either improve it or go to the next. This is really a component architecture marketplace, where you pay for goods by paying attention to someone’s work. And for most developers, that’s plenty of reward.

These environments are not only exciting, but are much more advanced than the agile consultants tend to understand. Consultants tend to work with groups that are struggling. The groups who really get it, who are really sailing, tend not to call consultants. The fun part of all this, as someone who got into agile early, is that I can look at what others are doing and where they’re taking it. That’s true as well with Wikipedia. You can imagine how much fun that is. It’s like watching your children grow up.

Now you’re working on another “child”: a collaborative video project. I’m having trouble imagining what it will look like with it grows up.

It’s like trying to imagine a wiki before there ever was one, and I don’t claim to have all the answers. Mostly, it’s about getting the computer and the camera to work together to make effective use of the network bandwidth, in order to collaborate with the people around you. And of course, as always, each step we make forward gives us some insight into the next step forward.