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: 1014db,d95b511473b3a931 X-Google-Attributes: gid1014db,public X-Google-Thread: f43e6,8ff817fc5c863f82,start X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,d95b511473b3a931 X-Google-Attributes: gid103376,public From: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) Subject: software engineering and the notion of authorship Date: 1996/07/05 Message-ID: <4rjhv6$ilu@mulga.cs.mu.OZ.AU>#1/1 X-Deja-AN: 163885450 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> organization: Comp Sci, University of Melbourne newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.software-eng Date: 1996-07-05T00:00:00+00:00 List-Id: 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.