Ward Cunningham
Computer programmer, most famous as the inventor of the first wiki, which was first called WikiWikiWeb, and one of the pioneers of software design patterns and Extreme Programming.
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.
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.
Wiki helped define the category of social software.
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.
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.
People who understand their collective goals and values are pretty good at self-organizing -- as long as they are allowed to.
Wikis work best in environments where you're comfortable delegating control to the users of the system.
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.
A wiki is a work sustained by a community.
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.
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.
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.
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.
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.
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.
What you get as a wiki reader is access to people who had no voice before.
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.
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.
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.
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.