Re: who owns the code? was Re: Distinguishing type names from other identifiers

[dewar@merv.cs.nyu.edu (Robert Dewar)]

<<Well i have, and my experience is that the ONLY place i saw it work is
the GNAT team.  It works very well at ACT in fact, but you have a very
atypical bunch of folks to work with.  The ACT folks are all at the top
of the curve for their respective levels of experience.  I am in fact
doing a kind of audit for a large software project in the avionics
domain where this approch is one of the primary reasons this project is
in so much trouble.  yes everyone works on everything, but the other
side of the coin is no one is really expert in anything.  everyone is
constantly doing a learning curve!  i agree with your point that there
are projects where only a single person can modify key pieces of code,
i have been there as well.  Thats why the folks i work with do
walkthroughs, read each others code to learn new techniques etc. there
is a middle ground between the two extremes.  What is important is for
people to be pragmatic and blend both approches!
>>

It sounds like you are describing a badly mismanaged project. There is
no doubt that team projects of the kind I describe require very careful
management, and indeed are not easy to manage. I have seen this approach
work well more than once. I also received a note from one programmer
on some aerospace project who reacted that what I described was exactly
what they did and that it worked very well.

Note that in the GNAT project it is absolutely NOT the case that 
everyone works on everything. That is hard to imagine as a model.
The model is that there are no set limits on what people work on. 
However, of course interest areas and expertise areas definitely
develop, and in the case of GNAT, there will typically be 2-3
people who know a given unit well, and are the most obvious people
to work on it. However, when necessary people can definitely stray
outside their area of primary expertise, especially when a simple
fix or addition is involved.

The situation of no one being expert in anything is of course a scary one.
My model is that people should be expert in a variety of things. You may
also comment that this approach presumes very good people. That is true.
I have always taken the viewpoint that a software project is better off
with a smaller number of more competent programmers. The difficulty of
managing N people for a given value of N is *certainly* not made easier
by having less than fully competent people, if anything it is made
harder, and the difficulty of managing N people climbs rapidly as N
climbs.

Other things being equal, i.e. in particular the ability to get the job
done, the fewer people working on a project the better.

I don't for a moment present my model as something that can be achieved
in all circumstances, indeed in most project environments there are a
sufficient number of people committed to the personal ownership model
that imposing something different may be extremely hard, especially if
there is no one who can effectively dictate how things will be done.

But still, remember that the original motivation of this thread was the
discussion of the value of absolutely consistent coding standards. This
is an easy-to-achieve first step towards being able to work better as
a team, and is something that, with competent programmers who recognize
the value of consistency of style, is easily achieved.