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: 103376,2afac1a4161c7f35
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: who owns the code? was Re: Distinguishing type names from other
 identifiers
Date: 1998/01/22
Message-ID: <dewar.885475413@merv>#1/1
X-Deja-AN: 318316246
References: <884736089.2104295427@dejanews.com> <69lael$90o@top.mitre.org>
 <01bd2207$18f3fac0$95fc82c1@xhv46.dial.pipex.com> <dewar.884945034@merv>
 <69nt40$q7n@top.mitre.org> <dewar.884996184@merv>
 <Pine.BSF.3.96.980116171810.3901B-100000@shell5.ba.best.com>
 <69rnvv$gjr@drn.zippo.com> <dewar.885126007@merv> <69t6fe$brl@drn.zippo.com>
 <dewar.885163403@merv> <6a00v3$ald@drn.zippo.com> <dewar.885243237@merv>
 <34C54EE3.C596CD72@mhv.net> <dewar.885398496@merv> <6a6bp1$sre@drn.zippo.com>
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 885475765 22622 (None) 128.122.140.58
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1998-01-22T00:00:00+00:00
List-Id: <comp.lang.ada>


nabassi says

<<you really can have people working together towards one thing and have
individual responsibility and the healthy ownership that comes with it at the
>>

Yes, this can be achieved, where on earth did you say me see that it could
never be achieved. 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. 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 (in France, and many other companies, the more
common practice is for the transition from one job to another to be less
frequent, and when it occurs, more gradual).

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. 

There is a lot written about these issues of team dynamics in software
projects, you might want to hit the literature!