Ward Cunningham Quotes

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.

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.

When I was at Tek, I was frustrated that computer hardware was being improved faster than 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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.