A Conversation with Ward Cunningham, Part I

---

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.

Getting the Big Picture

Bill Venners: How does the reader get the big picture of what's all there in a wiki?

Ward Cunningham: The first thing you have to understand is that because we made wiki easier for authors, we actually made it harder for readers. There is an organization there, and the organization can be improved, but it isn't highly organized. So the feeling for a reader is one of foraging in a wilderness for tidbits of information. You stumble across some great ones and you say, "This is fantastic, why doesn't somebody just make a list of all the great pieces so I don't have to look at the rest." In other words, "Why doesn't somebody organize this so I can get answers to my questions quickly?" Sooner or later they realize, "Gee, I could do that." They put in a month or two of finding what they care about, and then they make a page, which is their take on what the organization of wiki is.

I'm not a fan of classification. It's very difficult to come up with a classification scheme that's useful when what you're most interested in is things that don't fit in, things that you didn't expect. But some people decided that every page should carry classification. They came up with a scheme, based on page names, to establish a classification structure for a wiki. And these people who care about classification maintain it. If someone authors a page and fails to classify it, somebody else will say, "Oh, this should be classified as wiki maintenance or design patterns."

Bill Venners: How would they categorize a page as wiki maintenance?

Ward Cunningham: They just make a reference to a page named WikiMaintenanceCategory. You click that link, it goes to the page that explains the category and why the category exists. So to put a page into a category, the convention is to put a link to a page that describes the category. That makes the page tagged. If you want to understand what the category is, you follow the link to the category page. If you want to see what pages are in that category, you search for every page that references that category page.

Bill Venners: I suppose searching is one way I could begin exploring a new wiki. In a sense a wiki is like a very small version of the internet. Everything is all over the place. How will I find what I'm looking for? I could start by searching with keywords.

Ward Cunningham: That's right. People decided that any wiki page whose name ends with "Category" is a search term that's worth searching for. You might look for fiction on Google, but if people didn't label their work fiction, you might not find it. The category system is a set of pages that explain the rationale for the categories, and you can read those pages. They took a small part of the namespace—all those words that end with the word "Category"—and established the precedent that those pages talk about categories of other pages. It's great. It's in balance. If I tried to engineer a solution, it couldn't be as simple, or even as good. And what I love about it is, there is an active community who manages what the set of categories are. Sometimes they get the categories wrong, but then they correct them.

The Temporal Element of Wiki

Bill Venners: What you've described reminds me a bit of brainstorming. You gather some people together to flesh out something you can't clearly see.

Ward Cunningham: Wiki has a feel of brainstorming, though it's not as interactive. You can do 10 minutes of brainstorming, and 30 minutes of analysis of the product of that brainstorming, and have something in 45 minutes. The pace on wiki is slower. You could write a page about an idea, or maybe a page about a bunch of ideas. Then you could come back in a week and see what's developed on that page. But if you came back in 15 minutes, not much would have happened. Things happen in a pace of days or weeks on wiki, because people tend to browse by the day or week.

There's an interesting temporal element to wiki. If you read news groups or email lists, there's the sense that the right now is what's on your position in the list. And if you get behind, it's a struggle. I didn't want there to be a chronology in wiki. If you're reading something in a wiki, I didn't want it to matter to you whether it was written a year ago, a day ago, or just a minute ago. That means that we needed some way for getting the context.

If you're writing just a page, that page has to be in response to something else. So what you do is say in a paragraph what the page is about in the context of all the other pages. People become very familiar with those page names. They'll come across a new page and read the paragraph with the links to the context pages. If they already know those pages, they'll keep on reading. If they don't know those pages they'll say, "Oh, this page doesn't make any sense. I have to go read those other pages." So, if you know the context, you don't have to look. But if you don't know the context, you can go read it. The context stays there.

Bill Venners: It sounds like you kind of have to get to know a wiki site. By spending time there you become familiar with it. In the beginning it can be quite bewildering and not very informative, when you come in and see these things all over the place that are not necessarily organized for the reader.

Ward Cunningham: Right, a wiki is always in the process of being organized. But for every hour spent organizing, two more hours are spent adding new material. So the status quo for a wiki is always partially organized.

Wikis and Readability

Bill Venners: I really like the idea of a wiki, but I find it hard to read many wiki pages. The readability issue is the main reason I've never put a wiki on Artima.com. Artima.com is also a kind of web-based collaborative document, but more structured. In wiki, there's no single editor organizing the material for the reader. All the pages are collaborative. The structure is collaborative. The editing is collaborative. What do you get from the collaboration in wiki that is worth the tradeoff in readability?

Ward Cunningham: What you get as a wiki reader is access to people who had no voice before. The people to whom we are giving voice have a lot of instinct about what it's like to write, and ship, a computer program. Our industry honors certain traditions in its publications. If you want to contribute to a scientific journal, for example, you should be peer reviewed. Part of peer review is that you're familiar with all the other literature. And the other literature somehow that spiraled off into irrelevance. What was being written about programming didn't match what practicing programmers felt. With wiki, practicing programmers who don't have time to master the literature and get a column in a journal that's going to be read have a place where they could say things that are important to them. The wiki provides a different view. In fact you can tell when someone is writing on wiki from their personal experience versus when they are quoting what they last read.

Bill Venners: How do you tell?

Ward Cunningham: You can tell by whether they talk about things such as "Mary Ann just couldn't get this part to work right." That's not in the scientific tradition. If someone quotes an author and says, "So and so says bla de bla, and you guys are stupid to not listen," there's a guy who admires the books he reads. On the other hand, if someone says, "You know, for the last three projects we've tried to do this and it hasn't worked one single time. We've always been forced to do something else to get it out the door," there's a guy who's got it out the door, and he's telling me something profound. How to interpret that is left to me. It's just his experience. And then you might see a few more paragraphs that say, "Yeah, that happened to me but we got it out the door this other way." Now there are two ways to get it out the door. All of a sudden you're talking to the people who get software out the door, not the people who talk about getting software out the door, and that's a big distinction.

Next Week

Come back Monday, October 27 for the first installment of a conversation with Bertrand Meyer. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.

Resources

Bo Leuf and Ward Cunningham are the authors of The Wiki Way: Quick Collaboration on the Web, which is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/020171499X/

Ward's Wiki:
http://c2.com/cgi-bin/wiki?WikiWikiWeb

Ward's Weblog:
http://www.artima.com/weblogs/index.jsp?blogger=ward

Portland Pattern Repository:
http://c2.com/ppr/

Information on CRC (Class-Responsibility-Collaboration) Cards:
http://c2.com/cgi/wiki?CrcCard

XProgramming.com - an Extreme Programming Resource:
http://www.xprogramming.com/

FAQ-O-Matic:
http://faqomatic.sourceforge.net/fom-serve/cache/1.html

PLoP, the Pattern Languages of Programming conference:
http://jerry.cs.uiuc.edu/~plop/

Talk back!

Have an opinion? Readers have already posted 1 comment about this article. Why not add yours?

About the author

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima.com. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project that produced the ServiceUI API. The ServiceUI became the de facto standard way to associate user interfaces to Jini services, and was the first Jini community standard approved via the Jini Decision Process. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community. He currently devotes most of his energy to building Artima.com into an ever more useful resource for developers.