Re: software engineering and the notion of authorship

[z007400b@bcfreenet.seflin.lib.fl.us (Ralph Silverman)]

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 <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
: WWW: <http://www.cs.mu.oz.au/~fjh>   |  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