Bill Venners: The collective code ownership aspect of Extreme Programming (XP) reminds me of wikis, where everybody is in charge of everything.
Ward Cunningham: That's absolutely intentional. 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. So for example, say there's a problem in bunch of code. You know the solution to the problem, but the solution touches a bunch of modules. The needed refactoring is a lot of hard work, and it's made even extra hard if you has to go negotiate with every original author. You just want to go make it right.
The trouble is 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.
Bill Venners: Resistant?
Ward Cunningham: The program develops a resistance to a certain kind of knowledge—knowledge that wasn't anticipated—because you can't easily express the knowledge within the structure that was laid out at the beginning. It's not easy to put in anything that doesn't fit within that structure.
In wiki there's also a little bit of that resistance to ideas that are outside of what was anticipated, but the resistance is primarily in people's practices. The more that gets written in a wiki the more it gets rigid in its own right, but if somebody wants to change something and they're willing to go to 25 pages to do it, they can go to 25 pages.
For example, one process that happens in wiki is that pages evolve from discussion to essay. A lot of people want to read a discussion. The people who come to the wiki every day want to see what was said yesterday, so they want chronologically organized pages. But the sequence in which contributions were made is not a very good organizing principle for learning. So pages have kind of a discussion feel until the discussion dies. Later, someone comes back and reads the discussion and reformulates what you might call a thread-mode page into a document-mode page.
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. That's what we'd like to see in software.
Software has the advantage that it has a precise interpretation. Because software is written for a machine, we can rely on the precise interpretation to write tests. We can test that we haven't damaged or lost anything when we refactor a program. Whereas wiki, which is written for people, has no precise interpretation. I might say, "Gee, I'll pull this sentence up here and cut half of it out, because in this context it's easy to understand." Well I could be wrong. It could be easy for me to understand, but it might be hard for other people, and I don't have a test. So we probably lose information from wiki in the course of 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.