Software Designers~The People Behind the Code~(英語)

#27 Ward Cunningham: wiki inventor; agile programming pioneer; CTO, CitizenGlobal

この記事を読むのに必要な時間:およそ 6 分

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 wikis best virtue is not the hyperlinks that connect pages the way a shuttle connects terminals, but the wikis ability to foster collaboration. Every wiki is its own universe, and when people get to the edge, they cant resist the opportunity to expand it.

Constant expansion marks Cunninghams 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 movements founding document. Professionally, he was a principal engineer at the Tektronix Computer Research Laboratory, an architect in Microsofts Patterns & Practices Group, and, most recently, chief technology officer for

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 CitizenGlobals 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 Cunninghams 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 thats otherwise hard to reach. Through collaboration, people can make something on a wiki that they couldnt make on their own. Its interesting that a wiki in its simplicity is enough to engage that collaboration when so many more complicated tools cant seem to do it.

Why do you think that is?

One thing thats 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 didnt 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 thats unknown. In Wikipedia, thats done with red links. When you click on one, you get a note saying in effect: “We dont know--why dont you tell us?” Similarly, people would come to my desk and start browsing my database, and they couldnt 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: its 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 didnt 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 thats kind of boring, everybody already knows what an encyclopedia is. Here Ive invented a new medium, and theyre putting old stuff on it. But of course, its now clear that Wikipedia isnt just an encyclopedia. Its 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. Ive worked with companies where weve spent a year or two working on a project, only to discover they cant deliver it. So the thought was: lets write a one-week version of the project and “deliver” it, then “deliver” a better one the following week. In other words, lets practice delivering it. A partially completed project is still worth delivering, and that idea is similar to that of finding value in incomplete hypertext. Its only when youre 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: youve 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 youre 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 bulls 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 theyre 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 dont know how to communicate on shorter time scales when were 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 arent quite as fast as a jazz band on the first note, but theyre 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 wouldnt try anything unless they had seen it work before. They didnt 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 doesnt 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, youve 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 its 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: theres just an assumption that youll 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 youre 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 someones work. And for most developers, thats 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 theyre taking it. Thats true as well with Wikipedia. You can imagine how much fun that is. Its 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.

Its like trying to imagine a wiki before there ever was one, and I dont claim to have all the answers. Mostly, its 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.


Bart Eisenberg

Bart Eisenberg's articles on the trends and technologies of the American computer industry have appeared in Gijutsu-Hyoron publications since the late 1980s. He has covered and consulted for both startups and the major corporations that make up the Silicon Valley. A native of Los Angeles and a self-confessed gadget freak, he lives with his wife Susan in Marin County, north of San Francisco. When not there, he can sometimes be found hiking with a GPS in the Sierra, traveling in India, driving his Toyota subcompact down the California coast, or on the streets of New York and Tokyo.


1980年代後半より,『Software Design』や『Web Site Expert』などの雑誌に,アメリカのコンピュータ業界のトレンドと技術に関するレポートを執筆しています。シリコンバレーで,スタートアップ企業から大企業まで幅広い分野でコンサルタントを務めました。

ロサンゼルス生まれで,自称ガジェットフリークです.現在,妻のSusanとともに,サンフランシスコ北部のMarin County在住。また,SierraのGPSを携えてハイキングしたり,インドを旅したり,カリフォルニア海岸をドライブしたり,NYや東京の街中を歩いたりしています。