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

[dewar@merv.cs.nyu.edu (Robert Dewar)]

nabassi says

<<owning something DOES not mean that no one can look at each others work, it
just means programmers repsect each others work, and giving some feeling
of ownership to one's work will motivate programmers to improve their
work more, since their name on on their work going out of the door.

If my name is on a package, I am much more likely to try more to make
sure there is nothing wrong with it, if the department name is stamped on
every thing leaving that department, one is less likely to try to do the best,
since if something goes wrong, no one is responsible, it is the "department"
or the "group" that is resposible.
>>

Well it is certainly nice to have people illustrating what I am talking
about. This kind of "ego-centered" program (look at this it is mine!)" is
to me a very negative aspect, and a good software manager should try to
eliminate it.

It is absolutely NOT a necessary ingredient in motivation. It can be
replaced by "look at this, it is ours!" and I find that a MUCH more
constructive viewpoint.

I realize that there are all sorts of viewpoints here, but the above quote
from nabassi *exactly* represents the kind of thinking that I think can
be highly detrimental to high group productivity.

The big difference is that nabassi's view is that if names are not stamped
on each component then "no one is reponsible" [an exact quote, as you see].
My view of what you are aiming for is everyone feeling that everyone is
responsible. That's a much more constructive attitude.

The trouble with the "it's mine" viewpoint is that everyone concentratesw
too much on the part that is theirs, and not enough on the system as a
whole. The result is that some components will be fine, and other
components will be weak, and if you have a centered view that you won't
take responsibility for anything  except that which is "yours" [note
that this is an EXACT conclusion from the above paragraph], then there
is no one to take responsibility for the weak parts except the creator,
who quite likely was not well trained, or equipped, or capable of doing
the job right. In a group dynamic, people step in whereever they are
needed and take a group pride in what they create as a group.

Note that there is nothing new in what I am saying here, these are old
ideas. I did not invent the term "egoless programming"!