Advertisement

Summary
Ward Cunningham talks with Bill Venners about using wiki for collaborative exploration and the tradeoff between wiki authors and readers.

In the software community, Ward Cunningham has a reputation for being a font of ideas. He invented CRC Cards, a technique that facilitates object discovery. To facilitate the discovery and documentation of software patterns, he invented the world's first wiki, a web-based collaborative writing tool. Most recently, Cunningham is credited with being the primary inspiration behind many of the techniques of Extreme Programming.

On September 23, 2003, Bill Venners met with Ward Cunningham at the JAOO conference in Aarhus, Denmark. In this interview, which will be published in multiple installments on Artima.com, Cunningham gives insights into wikis and several aspects of Extreme Programming. In this initial installment, Cunningham discusses using wiki for collaborative exploration and the tradeoff between wiki authors and readers.

Why Wiki?

Bill Venners: What were your goals when you created wiki?

Ward Cunningham: I had a few things that I wanted to accomplish when I created wiki. My specific purpose for the first wiki was to create an environment where we might link together each other's experience to discover the pattern language of programming. I had previously worked with a HyperCard stack that was set up to achieve the same kind of goal. I knew people liked to read and author in that HyperCard stack, but it was single user. When we started the PLoP [Pattern Languages of Programming] series of conferences, and realized that what we really wanted to do was start a new literature, I decided that I needed to take that HyperCard stack and find a web equivalent.

I also had more general goals for wiki. First, I think there's a compelling nature about talking. People like to talk. In creating wiki, I wanted to stroke that story-telling nature in all of us. Second, and perhaps most important, I wanted people who wouldn't normally author to find it comfortable authoring, so that there stood a chance of us discovering the structure of what they had to say.

Bill Venners: What about a wiki makes it comfortable to author?

Ward Cunningham: Someone not familiar with authoring may have an idea, and the idea is a paragraph's worth of idea. They would write an editorial for a magazine, except a paragraph is too small. To write for a magazine, they would have to establish the context, say something important, say it in a way that a wide variety of people can understand it, and then bring it to a close. That's more than most people want to invest.

But if you're reading somebody else's work, and you think, "Yeah, but there's another point," being able to drop in a paragraph that says, "Well, yeah, but there's actually this." There's an awful lot of counterpoint, the "Yeah, but..." kind of thought, on wiki. Discussion groups do the same thing, but with discussion groups it all gets lost.

Bill Venners: Why does it get lost in discussion groups?

Ward Cunningham: Because you can't keep up. There isn't a context. Discussion groups tend to keep covering the same ground over and over again, because people forget what was said before. I think the invention of the Frequently Asked Questions, the FAQ, was a response to that. A lot of times just reading the FAQ is more valuable than joining the discussion group. When I first did wiki, there was a system called FAQ-O-Matic, which was the same idea as wiki, only really aimed at making FAQs. I looked at that and I thought, "Yeah, that's the same idea." But then I thought, "No, I prefer the more document-oriented form to the question-and-answer form." The patterns that we were trying to create in our literature were kind of like a FAQ, but could be more. There are probably 10,000 or 15,000 patterns on the wiki right now, documented on 25,000 pages.

Bill Venners: What do you think are good applications for wikis? Where does wiki really shine?

Ward Cunningham: A wiki works best where you're trying to answer a question that you can't easily pose, where there's not a natural structure that's known in advance to what you need to know. For questions like, "What's going on in the project," we could design a database. But whatever fields we put in the database would turn out to be what's not important about what's going on in the project. What's important about the project is the stuff that you don't anticipate.

Wiki pages are very much free form. Across the whole wiki there is a hypertext structure, but on a given page, within the versatility of your command of your natural language, you can say whatever needs to be said. So wikis are a good way to track project status. You can think of our patterns work, for example, as one long running project. We didn't know what the destination was, but we wanted to capture it as we went.

In addition, wikis work best in environments where you're comfortable delegating control to the users of the system. There isn't a lot of logic in wiki about who can do what when, because wiki doesn't really understand what you're doing. It's just holding pages for you. Lot's of conventions are established for what is or isn't an appropriate use, but they're all in the minds of the users not in the business logic of the application. That works well if you have a trusting community that isn't looking for the computer to enforce some behavior. I've been asked sometimes whether wiki would fit in a corporate environment, for example. I think there are corporations that are together enough to have this trust of their own employees, and there are certainly corporations that aren't. Corporations that wouldn't trust their own employees to be able to maintain a web site need something other than wiki.