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

[nabbasi@earthlink.net]

In article <dewar.885475413@merv>, dewar@merv.cs.nyu.edu says...

>What I *did* say, from my experience with dozens of
>different projects, is that all too often "ownership" is not at ALL
>healthy. It is constantly a surprise to me to find out cases where a
>large company has a big project and there are pieces of it that no one
>knows and hence which cannot easily be modified. 

well then Dr. Dewar, it seem then that you have been on a dozen 
projects where the management of those projects were bad and not 
organized and incompetent, so what is new?

A manager who does not know who is responsible and who currently working on
every piece of the system is a bad manager, do not fix this by the
drastic solution of having every one owning everything and no one owning
anything. Your solution to the problem seems to me worse than the 
problem itself.

>The reason in every case
>is that the single person who owned and knew the code left the company,
>and, as is the (rather odd) practice in the US, this was done with virtually
>no warning, very abruptly 

Again, you come up with a second problem which can be solved without 
abandoning the model of healthy ownership and the individual responsibility.

This is a management issue to make sure communication is always open 
between people while they are working of the project, regular 
design and discussion meeting between the members of the group so 
that people are more familiar with each others work, (I am all for
people being familar with each others work) and to ask for each 
programmer to have a well written document about his or her
work, so that when the programmer leaves (without giving the 
normal 2 weeks notice that they should do) the group is not left 
wondering what was that programmer working on and how to carry on afterwords.

So, you blamed lack of communications, little or no group meetings, 
no well defined means of communications between people, no documentation, 
etc.. on the ownership model, and you want to replace that with your 
model, hoping suddenly the management will wake up and that programmers
who did not communicate before will now start to and all will be fine.

>
>Yes, this can be avoided. All I am saying is that my preferred way of
>avoiding this is to strive for the kind of model I have described. 
>

All what I am saying is that your solution is to the wrong problem. The
problems you mentioned with the healthy ownership model (people 
leaving suddenly, people not knowing who is working on one part of 
the system) can be solved by fixing the management and by having 
more communications between people, and the other things I mentioned
above, these  things need to be done under any model.

regards,
Nasser