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

[jhopper@erinet.com (James Hopper)]

In article <dewar.885515552@merv>
dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> 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.

Its unfortunate but this project has first rate people who can't seem
to mesh.  I agree is a management problem, but i also belive that its
made worse by this model.  I tend to belive that the egoless model
might make a first rate team better, but it can also, in my opinion,
make a team that hasnt gelled MUCH worse in many cases.  the question i
would ask as a manager is is the return worth the risk?  Its a case by
case call i expect

> 
> 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.
> 

I think this is the crux of my difference with you robert.  I would
probably agree that a team is composed of smaller subgroups who
specialize (as oposed to own) an area of the problem domain.  Your
description up to now kind of gave me the impression that you were
advocating anyone could at any time work on anything, if no one owns it
than no one controls it i guess is my thinking.  I admit that could be
my own pre-concieved notions at work.  If this type of subgroups is
what you are talking about then i think we can agree, as thats closer
to my groups method of operation.  

Oh and since some of the SAIC folks do read this group let me hasten to
mention that the folks i work with at SAIC are everybit as first rate
as anyone elses 

;-)  We have a really great group of folks who work very well togeather
as a team for a very long time on our Radar simulation product line.


> 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.

Yes, one of the things i enjoy about working with the radar team at
SAIC is its one of the very few groups i work with where i can read and
modify the code and not want to start reformatting/rewritting it. We
have worked togeather and learned togeather so long that our styles
mesh very well, at least from my point of view.  i can usually tell
differences in style when working with other groups, this group its
rare that i feel this.  Let me add that working with the gnat code is a
similar experience in that its all pretty much one style its just that
its different from the style i use most of the time.  But i have
learned to adjust when working with gnat code.  Of course the style
checks in the compiler help that a lot ;-)