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.