Ward Cunningham talks with Bill Venners about 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.

Read this Artima.com inteview with Ward Cunningham:

http://www.artima.com/intv/ownership.html

What do you think of Ward's comments?

This is the best conversion I've read. I wish I work for him.

Ward,

In what way does the requirement that all developers have a working knowledge of the complete code-base act as a constraint on the size or complexity of said code-base?

Vince.

> In what way does the requirement that all developers have
> a working knowledge of the complete code-base act as a
> constraint on the size or complexity of said code-base?

Place that comment within the context of agile practices. There would be fewer than a dozen developers, so the codebase would be relatively manageable. So, it seems you have to divide large projects into (mostly) independent chunks beforehand.

It's clear that this paradigm of collective code ownership would not scale to huge projects without limiting the size of the group and the sub-project itself.

Alex

> It's clear that this paradigm of collective code ownership
> would not scale to huge projects without limiting the size
> of the group and the sub-project itself.

I would argue that in many cases the project does not need to be huge in the first place.

Dave

> Place that comment within the context of agile practices.

(My apologies, Andy, for misusing your comment.) It seems to me that this whole concept hinges on an ideal; a project having a staff of knowlegeable, conscientious programmers who respect each others ideas.

The reality is that most people don't know that they don't know. (Please refer to Bruck Eckel's note on incompetence for more on this. http://mindview.net/WebLog/log-0023) Instead of being humble and open-minded, like you Ward, they force their poor ideas on others, and will hear of no complaints from the peons who "clearly aren't intelligent enough to appreciate my brilliance."

The only defense against this is to divy up the code into chunks, so that at the very least, you can get your job done without people rewriting the code out from underneath you.

I know that this is a very cynical view, however, for many of us, this is our day-to-day existence. Those like myself won't stay long in this type of environment; we'll move on to greener pastures. The others, I'm afraid, believe that things are perfect the way they are.

As a separate note, but tied to Ward's article, it's been eye-opening to me to finally understand some of the motivations for existing configuration management (CM) processes.

One thing that's become clearer to me in recent years is that management is hung up on rigid CM processes because the cost of errors has been high. And further, the cost of experimentation in other engineering fields is high. For example, you can breadboard a circuit but that's a long ways from production. And the problem of getting from prototype to production is expensive for hardware, plus mistakes are even more expensive.

With software, there's a change. The cost of mistakes doesn't have to be high (unless we make it high). And the cost of experimentation is relatively low, compared to other engineering fields.

One thing I've been trying to sell to some management people I know is the idea that CM for software is fundamentally different than CM for hardware. They don't want to buy the idea. But more and more, I am becoming convinced that software is a different thing, and that ideas like collective ownership are going to slowly expose this radical difference.