A Conversation with Ward Cunningham, Part II

---

In the software community, Ward Cunningham has a reputation for being a font of ideas. He invented CRC Cards, a technique that facilitates object discovery. He invented the world's first wiki, a web-based collaborative writing tool, to facilitate the discovery and documentation of software patterns. Most recently, Cunningham is credited with being the primary inspiration behind many of the techniques of Extreme Programming.

On September 23, 2003, Bill Venners met with Ward Cunningham at the JAOO conference in Aarhus, Denmark. In this interview, which will be published in multiple installments on Artima.com, Cunningham gives insights into wikis and several aspects of Extreme Programming.

• In Part I: Exploring with Wiki, Cunningham discusses using wiki for collaborative exploration and the tradeoff between wiki authors and readers.
• In this second installment, Cunningham discusses how he designed wiki to be a model for collective code ownership, collective incentives for pride of ownership, and how to deal with disagreements by eliminating the cost of making mistakes.

Collective Code and Text

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.

Collective Incentives for Quality Code

Bill Venners: I see the benefit of collective code ownership as you've described it. What is the cost? What is the disadvantage of collective code ownership?

Ward Cunningham: I'm sure there's something but I can't think of anything right now.

Bill Venners: How about pride of ownership? Do people adapt to collective pride? When something is your own creation, you want to make it good.

Ward Cunningham: I think that the collective ownership is actually better for that. Yes, I have a lot of pride in what I do. Pride is a motivator for me. But with collective ownership, we essentially create a small community of people who have trained themselves to appreciate what I do. Whereas if I had ownership, people would say, "Well that's Ward's module. I don't want to look at Ward's module." Maybe they'll like the API to Ward's module, if they have to call it. Maybe they'll be impressed that the bug rate for my module is low. But they might say, "Well, he had a simple module. He had an easy-to- write module. That's why his bug rate is low." They wouldn't know.

When people work the material that I produce, they can feel whether it is easily worked or not. By working the material, I mean taking the code and adjusting it to do a little more or act a little differently—whatever has to be done with the code. 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.

Now, it doesn't have my name on every line. In fact, it turns out that when it gets really good it might be because they made it good, not me. I might have just set the course, and then they filled it out and made it good. I might get credit I don't deserve, but they might be passing compliments out to other people too. 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.

Bill Venners: Why doesn't the same thing happen to collectively-owned code that happens to wiki pages, where things sometimes get disorganized for a while?

Ward Cunningham: I think it does, sure.

Bill Venners: You were just talking about how it's not always obvious who wrote a particular line of code. That's also true of a wiki page. It's not always obvious who wrote a particular line of text. Sometimes people write on a wiki page, "I had this experience," and as a reader I don't know who "I" is. What's different about collective code ownership compared to collective text ownership that let's you end up with cleaner code than you do text?

Ward Cunningham: I think it's very common to have code that's inscrutable. The code may work, but how it works is essentially encrypted. It is not possible to read. In fact, that may even be the norm. So, disorganized might not be the right word for it, but it certainly isn't readable. I've pair programmed long enough with people that I'll read their code and think it's my code. That hasn't happened with wiki, where I've read somebody's paragraph and thought it was my paragraph. Maybe that's because the code is more highly organized, but I think it might be instead that the range of discourse is so much narrower in code. That the range of discourse is about the computerization of some process, and the latitude of best ways to say it are pretty modest. So that might cause code to stabilize organizationally faster than English would.

Dealing with Disagreements

Bill Venners: In Extreme Programming Explained, Kent Beck writes, "Collective ownership increases your feeling of personal power on a project. You are never stuck with someone else's stupidity. You see something in the way, you get it out of the way." What happens when different people's ideas of what's stupid clash? Isn't stupidity a subjective judgment?

Ward Cunningham: Yeah, I wouldn't have said it that way. 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."

We shouldn't make ourselves so much fortune tellers that we have to predict the future. Better to set up the circumstances so you can try B and see what happens. Now, it turns out that often the difference is inconsequential. Whoever programs it has the freedom to program it the way they chose, and it is just fine. Of course sometimes it does turn out to be consequential. We're doing something else and we look at it and say, "You know, this isn't going to fit in there because B doesn't really let it fit in." And this problem might have been what I was thinking about when I was promoting A, or it might not. It might be that the developer squeezes it in within the context of B. But you sometimes get these bugs or difficult enhancements. And then the developer says, "You know, I'm sick of working on this code." I say, "Hey, I'll take that bug." And they say, "Would you?" I say, "Sure, I'll take the bug. You did B. I'll work on B." So I can go in and work on it, and I'll try to use as much of B as is worth using. But with taking on the responsibility, I get the opportunity to make it do what it needs to do.

Bill Venners: You mean go back to A.

Ward Cunningham: If that's what's required.

Bill Venners: Or perhaps go to C.

Ward Cunningham: Usually it turns out to be C. It's a learning experience for both of us. If we decide without the experience, neither of us really learns. Ward won, and somebody else didn't. Or vice versa. It's too much of a battle. Why not say, "Well, let's just code it up and see what happens. If it doesn't work, we'll change it."

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 something does go wrong, it doesn't cost you or your customer an exorbitant amount. It isn't ridiculously expensive. 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.

For example, in one project we eliminated the cost of a mistake with frequent releases. And we did it by building a fairly elaborate mechanism for database schema evolution. We'd release weekly and we'd do a schema change every week. We could make different schema changes for different customers in different orders, and have it all come together and be right in the end. And because we did it every week, after about six or eight weeks, we believed we could do it. We were never afraid to do it. Most people say, "Whatever you want to do, don't do schema evolution unless you really have to." And at the end of the project they say, "Oh my god, we really have to." So without ever doing it before, they say, "As long as we're going to do it, let's do all of it." They make a gigantic project, something they have no practice in. And what do you know? They get it wrong. By contrast, we do it every week. Do a little bit every week. We get really good at it. We're never afraid of it. It's never a problem.

So 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. It's really more the approach of asking, "What do you want to be good at?" If you want to be good at it, find a way that you get to practice every day. If you practice every day there's no way you can help but be good. So, pick what you want to be good at. Well, you ought to be good at what you're afraid of. Then you'll stop being afraid of it.

Next Week

Come back Monday, December 8 for the first installment of a conversation with Bertrand Meyer. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.

Resources

Bo Leuf and Ward Cunningham are the authors of The Wiki Way: Quick Collaboration on the Web, which is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/020171499X/

Ward's Wiki:
http://c2.com/cgi-bin/wiki?WikiWikiWeb

Ward's Weblog:
http://www.artima.com/weblogs/index.jsp?blogger=ward

Portland Pattern Repository:
http://c2.com/ppr/

Information on CRC (Class-Responsibility-Collaboration) Cards:
http://c2.com/cgi/wiki?CrcCard

XProgramming.com - an Extreme Programming Resource:
http://www.xprogramming.com/

FAQ-O-Matic:
http://faqomatic.sourceforge.net/fom-serve/cache/1.html

PLoP, the Pattern Languages of Programming conference:
http://jerry.cs.uiuc.edu/~plop/

Talk back!

Have an opinion? Readers have already posted 6 comments about this article. Why not add yours?

About the author

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima.com. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project that produced the ServiceUI API. The ServiceUI became the de facto standard way to associate user interfaces to Jini services, and was the first Jini community standard approved via the Jini Decision Process. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community. He currently devotes most of his energy to building Artima.com into an ever more useful resource for developers.