Ward Cunningham Quotes

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.

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.

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

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

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.

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

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.

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

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.

Sometimes when you collaborate, you have to trust people more than you have any reason to do so. It works because most people are good

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.

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.

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

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.