From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2afac1a4161c7f35 X-Google-Attributes: gid103376,public From: jhopper@erinet.com (James Hopper) Subject: Re: who owns the code? was Re: Distinguishing type names from other identifiers Date: 1998/01/23 Message-ID: <6a8vgd$cr7@nntp1.erinet.com>#1/1 X-Deja-AN: 318481776 Sender: -Not-Authenticated-[5490] References: <01bd2207$18f3fac0$95fc82c1@xhv46.dial.pipex.com> <69nt40$q7n@top.mitre.org> <69rnvv$ <6a8mir$caa@nn In article 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 ;-)