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: 109fba,d95b511473b3a931 X-Google-Attributes: gid109fba,public X-Google-Thread: fc89c,de62d506c7cf194a,start X-Google-Attributes: gidfc89c,public X-Google-Thread: 1696ae,de62d506c7cf194a,start X-Google-Attributes: gid1696ae,public X-Google-Thread: 103376,d95b511473b3a931 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,8ff817fc5c863f82 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1014db,d95b511473b3a931 X-Google-Attributes: gid1014db,public From: z007400b@bcfreenet.seflin.lib.fl.us (Ralph Silverman) Subject: Re: software engineering and the notion of authorship Date: 1996/07/15 Message-ID: <4sdhbg$r7e@nntp.seflin.lib.fl.us>#1/1 X-Deja-AN: 168826546 references: <4quk22$78@krusty.irvine.com> <4r059t$2at0@info4.rus.uni-stuttgart.de> <4r3bp1$cea@Starbase.NeoSoft.COM> <4rg3ph$2on4@info4.rus.uni-stuttgart.de> <4rjhv6$ilu@mulga.cs.mu.OZ.AU> organization: SEFLIN Free-Net - Broward newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.dos.programmer,comp.software-eng Date: 1996-07-15T00:00:00+00:00 List-Id: Fergus Henderson (fjh@mundook.cs.mu.OZ.AU) wrote: : In comp.lang.ada, dewar@cs.nyu.edu (Robert Dewar) writes: : >To me this "ego-centered" style of programming is deadly. It promotes a : >situation where in a big project code is owned by individuals. : I agree consistency is very important, as is maintainability. : It is essential to make sure that the overall design is consistent. : It is also essential that every part of the system is sufficiently : clear, well-documented, and so forth that any programmer could make : modifications to that part of the system, or take over responsibility : for that part of the system, and consistency of style is important : in facilitating this. But I'm not convinced that recording : authorship or assigning areas of responsibility is a bad idea. : >you lose the advantages of working as a team. : Teamwork has it's own disadvantages. In particular, productivity goes : way down! (See "The Mythical Man-Month".) If there is a problem : in a particular piece of code, it makes sense for the expert on : that subsystem to be the one to fix it. They'll be able to do : it quicker, and with less likelyhood of error, than someone who : is not an expert on that subsystem. It also makes sense for the : expert on a subsystem to be part of the code review team for any : changes to that subsystem, and assigning some degree of responsibility : to the expert can increase their motivation to do a good job of : code review. Of course you need to make sure that the code is : sufficiently consistent, well-documented, etc. that anyone can _become_ : the expert, when and if necessary. But it's impossible for everyone : to be the expert on everything. : >in the GNAT project ... You absolutely cannot tell : >who wrote code from its style, and indeed we strongly discourage the notion : >of authorship (we never for example attach names to units). Sure in practice : >certain people know certain code well and our informally the experts in : >particular areas, but if you look at the revision histories, you will see : >that all sorts of people work in all parts of the system. : What's wrong with recognizing the role of these informal experts? : >In my experience, as in sports, this team : >spirit is a key factor in maintaining a high level of motivation. : As in sports, I think it is useful to assign individuals particulars : areas of responsibility. In Australian rules football, a team has : forwards, a backline, centers, and on-ball players (rovers, a ruckman : or two, and so forth). It's not just a mob. : And while team spirit is important, so is individual motivation, and : a little bit of competition between players is a good thing, so long : as they're competing for success in meeting the team's objectives, : not competing for the ball. A team plays better if they have a good : reserves team, with players competing for spots in the team. And : players within a team compete for the team's best-and-fairest awards. : The important thing, IMHO, is finding the right balance. : -- : Fergus Henderson | "I have always known that the pursuit : WWW: | of excellence is a lethal habit" : PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. -- ************begin r.s. response************* a closely related question is: if persons who are supposed to be programmers can usefully work in groups or teams were such persons not able to program individually... ? generally, one may suppose, those capable of programming individually would be accepting of individuality . ************end r.s. response*************** Ralph Silverman z007400b@bcfreenet.seflin.lib.fl.us