Howard G. "Ward" Cunningham (born 26 May 1949) is a computer programmer, and is best known as the inventor of the first wiki, which is called WikiWikiWeb, and one of the pioneers of software design patterns and Extreme Programming.

Sourced

• Why have a locked wiki when you can instead just post static Web pages?
  • On the lack of sense in using the Wiki format for overly constrained or simply locked pages, in The Wiki Way: Quick collaboration on the Web (2001), co-authored with Bo Leuf

• When I was at Tek, I was frustrated that computer hardware was being improved faster then computer software. I wanted to invent some software that was completely different, that would grow and change as it was used. That’s how wiki came about.
  • "Startup mines for riches in collaboration software" in The Portland Tribune (4 March 2008)

A Conversation with Ward Cunningham (2003)

Interview with Bill Venners at the JAOO conference in Aarhus, Denmark (23 September 2003) published in several installments at Artima.com.

Exploring with Wiki

"Exploring with Wiki : A Conversation with Ward Cunningham" Part I (20 October 2003)

• 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.

• 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.

• 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.

• 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.

• 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.

• Wikis work best in environments where you're comfortable delegating control to the users of the system.

• 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.

• 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.

• 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.

• What you get as a wiki reader is access to people who had no voice before.

Collective Ownership of Code and Text

"Collective Ownership of Code and Text : A Conversation with Ward Cunningham" Part II (1 December 2003)

• In the months before I made wiki, we had been having an argument. I think Kent Beck and I were on one side. People who had a lot of faith in the prevailing dogma of software engineering were on the other side. We said, "Collective code ownership is good." They said, "That's ridiculous. You'll never get responsibility. You'll never get quality if you don't have responsibility. And the only way you'll get responsibility is ownership. You have to pin the bugs back on somebody if you want them to ever rise above producing bugs." And I said, "Well that's wrong."

• The decisions I made designing wiki were very much inspired by my desire to create a model for the collaborative process I thought should happen in large code bases. I wanted wiki to mimic that.

• The code might be organized in a hierarchy, but the solution has more dimensions than will fit in a hierarchy. So when you discover a solution in a dimension that crosses across the hierarchy, you just have to go where the solution takes you and put the solution in.

• All the time we find ourselves in situations where people know things about the program, but they can't apply that knowledge to the program. Why? Because the knowledge runs counter to some organizational decision that was made before they had that knowledge. In other words, the program becomes resistant to that collection of knowledge.

• Often as you move comments around and have similar comments adjacent to each other, you find that half of the words can be cut out. Because a sentence says it all if the sentence is in just the right place. On Ward's wiki, the process has been called "refactoring," which is what we call the process in software. Ward's wiki is about software and it has software people on it, so they call it refactoring. Anyplace else it would probably be called editing. So on Ward's wiki, refactoring is an ongoing process. The assumption is that when something turns out to not be ideal, it will be refactored again. Everything is subject to refactoring.

• Wiki is like a leaky bucket of information. It's losing information every day. But more information is coming in, so the net is positive. Even if it can lose things, wiki always has more to say than it did the day before.

• When people work code they can often see things I set out to do that they wouldn't notice otherwise. And there are no obligations to say, "Ward you're brilliant," but sometimes they say, "Ward you're brilliant." And that strokes my ego. Pride of ownership? You bet.

• The idea of where does an idea come from and who should get credit for it is pretty soft. But I think people are pretty good at dealing with that softness and recognizing contribution when they know the people involved. With collective ownership, we create a social situation where you can get to know a person by how they spin their intellect into source code statements.

• It was a turning point in my programming career when I realized that I didn't have to win every argument. I'd be talking about code with someone, and I'd say, "I think the best way to do it is A." And they'd say, "I think the best way to do it is B. I'd say, "Well no, it's really A." And they'd say, "Well, we want to do B." It was a turning point for me when I could say, "Fine. Do B. It's not going to hurt us that much if I'm wrong. It's not going to hurt us that much if I'm right and you do B, because, we can correct mistakes. So lets find out if it's a mistake."

• I can't tell you how much time is spent worrying about decisions that don't matter. To just be able to make a decision and see what happens is tremendously empowering, but that means you have to set up the situation such that when something does go wrong, you can fix it.

• When you get in situations where you cannot afford to make a mistake, it's very hard to do the right thing. So if you're trying to do the right thing, the right thing might be to eliminate the cost of making a mistake rather than try to guess what's right.

• We erased a problem by not trying to erase the problem, by saying, "This is in the nature of what we do." It's really weird that it could be that simple.

Working the Program

Working the Program A Conversation with Ward Cunningham, Part III (5 January 2004)

• Traditionally, the cost of change curve said that if we detect the need for a change early, it costs less to make the change than if we detect the need late. I tackled that curve by saying, let's almost intentionally make mistakes so we can practice correcting them. That practice will help reduce the cost of making changes late.
  Our feeling was that the limiting factor on any change was not when it was done, but how much thinking was required.

• You don't want to write a big comment that tells others how to make a change they might want to make, because you don't know what change they're going to want to make. Better to have the attitude that you can't help future programmers make their changes . All you can do is make it easy for them to understand what you were trying to do. And it will be easiest for them to understand what you were trying to do if you were very careful to not try to do too much.

• Over and over, people try to design systems that make tomorrow's work easy. But when tomorrow comes it turns out they didn't quite understand tomorrow's work, and they actually made it harder.

• I like the notion of working the program, like an artist works a lump of clay. An artist wants to make a sculpture, but before she makes the sculpture, she just massages the clay. She starts towards making the sculpture, and sees what the clay wants to do. And the more she handles the clay, the more the clay tends to do what she wants. It becomes compliant to her will.
  A development team works on a piece of code over several months. Initially, they make a piece of code, and it's a little stiff. It's small, but it's still stiff. Then they move the code, and it gets a little easier to move.

• Often, the program ends up amazing. You'll say, "This is beautifully architected." Well, where did that architecture come from?
  In this case, architecture means the systematic way we deal with diverse requirements. Architecture allows us, when we go to do work we need to do on the program, to find where things go. It is a system that was worked into the program by all the little decisions we made — little decisions that were right, and little decisions that were wrong and corrected. In a sense we get the architecture without really trying. All the decisions in the context of the other decisions simply gel into an architecture.

To Plan or Not To Plan

"To Plan or Not To Plan : A Conversation with Ward Cunningham" Part IV (12 January 2004)

• Honest to God, I think Kent Beck's contribution to all this has been taking stuff that he and I discovered quietly together, or picked up from other programmers, and taking it to the limit. Taking it to the limit. And the fact that it actually holds up — and a lot of it improves — when taking it to the limit is why it should naturally be called "Extreme." Kent's single biggest contribution is being daring enough to say, "This is all that matters, and we should do it all the time."

• To worry about tomorrow is to detract from your work today. Time you spend thinking about tomorrow is time you're not spending thinking about what to do today. The place you leave in the code because you think you'll need it tomorrow, is actually a waste of time today — and a liability tomorrow. It does more harm than good.

• Many people have experience with a program that's gotten out of control. They have an idea. They think they know what they want to do. But when they go to put the idea in, the idea is forgotten by the time they've figured out how to put it in.

• I love computer graphics, but every system I've seen to try to turn programming into pictures has lost that syntactic element. There's something about syntax that makes it very precise for reading. I love photography. A photograph will tell a story. But words tell a story even better. Words are more versatile. You can paint a verbal picture that's much richer than you can photograph.

• I could say, "Wait! Wait! I know what's going to happen down here!" Well you knew what was going to happen down here. How does it help us get our job done for me to tell you what's going to happen down here? You could say, "Stop! I want to draw on the white board what we're going to do tomorrow, because I can see it coming." Well maybe I can see it coming too, but why make a commitment? It will come soon enough. So, we're certainly here and now, but I think we can become excellent predictors. It's just that we're careful not to depend upon prediction anymore than we have to.

The Simplest Thing that Could Possibly Work

"The Simplest Thing that Could Possibly Work : A Conversation with Ward Cunningham" Part V (19 January 2004)

• I actually enjoy complexity that's empowering. If it challenges me, the complexity is very pleasant. But sometimes I must deal with complexity that's disempowering. The effort I invest to understand that complexity is tedious work. It doesn't add anything to my abilities.

• Computers are famous for difficulties. A difficulty is just a blockage from progress. You have to try a lot of things. When you finally find what works, it doesn't tell you a thing. It won't be the same tomorrow. Getting the computer to work is so often dealing with difficulties.

• The complexity that we despise is the complexity that leads to difficulty. It isn't the complexity that raises problems. There is a lot of complexity in the world. The world is complex. That complexity is beautiful. I love trying to understand how things work. But that's because there's something to be learned from mastering that complexity.

• What is simplicity? Simplicity is the shortest path to a solution.

• If you write a lot of programs, and you're used to squeezing them all the time, you find that it's easy to write a program that's simple. A lot of it is having a clear sense of what you want to say — writing the proof by choosing what to prove, and being clear about that. In programming, a lot of simplicity comes from knowing what matters and what doesn't matter.

• There is an art to knowing where things should be checked and making sure that the program fails fast if you make a mistake. That kind of choosing is part of the art of simplification.

• So today, let's write a program simply. But let's also realize that tomorrow, we're going to make it more complex, because tomorrow it's going to do more. So we'll take that simplicity and we'll lose some of it. But tomorrow, hopefully tomorrow's program is as simple as possible for tomorrow's needs. Hopefully we'll preserve simplicity as the program grows.

• Let's not worry about what somebody reading the code tomorrow is going to think. Let's not worry about whether it's efficient. Let's not even worry about whether it will work. Let's just write the simplest thing that could possibly work.

• You are always taught to do as much as you can. Always put checks in. Always look for exceptions. Always handle the most general case. Always give the user the best advice. Always print a meaningful error message. Always this. Always that. You have so many things in the background that you're supposed to do, there's no room left to think. I say, forget all that and ask yourself, "What's the simplest thing that could possibly work?"
  I think the advice got turned into a command: "Do the simplest thing that could possibly work." That's a little more confusing, because there isn't this notion that as soon as you've done it, we'll evaluate it.

• There's been an awful lot of discussion about what is or isn't simple, and people have gotten a pretty sophisticated notion of simplicity, but I'm not sure it has helped.

Geek Noise (2004)

Talk at MS Research (November 2004) as quoted at Geek Noise

• I don't claim to be a methodologist, but I act like one only because I do methodology to protect myself from crazy methodologists.

• When a manager asks for hard data, that's usually just his way of saying no.

• There is a programming smell here… which is kind of like the smell in your refrigerator, you know. There's a sign that there's something wrong, but you can't quite put your finger on it. But you know if you leave it there, its only going to get worse.

• What I'm really doing is I'm trying to preserve the right for a programmer to think while he's typing. If you feel that it’s not going well, you can stop and say 'What did I get wrong? Let me correct it.

Crucible of Creativity (2005)

"Ward Cunningham on the Crucible of Creativity" : Corante (17 October 2005)

• My hope is that wiki becomes a totem for a way of interacting with people. Tradition in the work world has been more top down, while wiki, standing for the Internet, is becoming a model for a new way of work. Largely driven by reduced communication costs, it changes what needs to be done and how it’s going to get done. I hope that the wiki nature, if not the wiki code, makes some contribution.

• A wiki is a work sustained by a community.

• The blogosphere is a community that might produce a work. Whereas a wiki is a work that might produce a community. It’s all just people communicating.

• One’s words are a gift to the community. For the wiki nature to take whole, you have to let go of your words. You have to be okay with that. This goes into the name, called refactoring. To collaborate on a work, one must trust. The reason the cooperation happens is we are people and it is deep in our nature to do things together.

• Cooperation has a transactional nature, we agree it is a mutual good. Collaboration is deeper, we don’t know what the transaction is, or if there is one, but if I give of myself to this collaboration, some good will come out of it. You have to trust somebody to collaborate.

• With wiki, you have to trust people more than you have any reason to trust them. In 1995, it was a safer environment, don’t know if I could have launched wiki today.

• Putting a new feature into a program is important, but refactoring so new features can be added in the future is equally important. The ability to do things in the future is something that I consider suppleness, like clay your hands that accepts your expression. Programs and documents get brittle very quickly. Wiki imagines a more dynamic environment where we accept change...

• Anonymity relieves refactoring friction. Have learned that people want to sign things. But try to write in a way where you don’t have to know who said it. But when someone who is not in a giving mood uses anonymity (spammers), that abuse can drive us away from anonymity. But I hope we can drive the ill-intended out without having to give up the openness.

• The web has been an experiment in anonymity. Conscious design of low level protocols. Lots of identity infrastructure has been created to make it an online shopping mall, which makes it unpleasant for all of us because the machinery isn’t that great.

• People can and do trust works produced by people they don’t know. The real world is still trying to figure out how Wikipedia works. A fantastic resource. Open source is produced by people that you can’t track down, but you can trust it in very deep ways. People can trust works by people they don’t know in this low communication cost environment.

• Top down hierarchies make communication work when it is expensive, I hope that wiki can be a flagship in this move in the industry to produce computer support for this kind of work and evolve organizational forms.

Podcast Interview with Ward Cunningham (2006)

Interview with Ward Cunningham at the EclipseCon in Santa Clara, California (23 March 2006) published as "Ward Cunningham discusses Eclipse, Wiki and Agile Development"

• Wiki helped define the category of social software.

• Global collaboration is something that Wiki mastered in a small way and here we can master it in a big way.
  • Speaking about Eclipse Foundation

• People who understand their collective goals and values are pretty good at self-organizing -- as long as they are allowed to.

• Accept that you've got a common goal that we're all working towards and that we're working towards the same goal. In other words, align and self-organize.

Foreword to Wikis for Dummies

Foreword to Wikis for Dummies (2007)

• Before wikis, computer writing was all about the words. The computer could help you type them, spell them, hyphenate them, size them, shape them, and align them. But when it came to developing your thought, well, you were on your own.

• Now, with wikis, you have a place to write. A wiki is a place to write in the same way that a party is a place to talk. There are thoughts all around you. Some are interesting, some less so. At a party or on a wiki, a word or two will be your trigger. Ideas start flowing. Talking or writing, you're among friends, the stage is set, you say your piece, it fits in, your words trigger the next thought: conversation.

• A wiki is like a party that doesn't have to stop. It's a party that doesn't get crowded because new rooms appear when needed. It's a timeless party where you can try each conversation over and over until you get it right.