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

[nabbasi@earthlink.net]

In article <dewar.885163403@merv>, dewar@merv.cs.nyu.edu says...
>
>OK, there it is, both negative aspects of code ownership! 
>

well, you call it negative I call it positive :)

> In
>particular, if you have this level of code-ownership viewpoints, you
>will very seldom get people reading other people's code in a routine
>manner. 

not at all. this is where code reviews comes in, this is where weekly
design meetings comes in, this is where white board brain storming comes in,
this is where good documenations by each programmer of what they are working
on comes in. this is being done all the time in all organizations (at least
I hope it is done).

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. 

>It is this many-eyes-on-the-code phenomenon which is valuable
>for code quality. 

sure, I agree, again, this is what code reviews are for.  you can have
as many eyes as you want looking at the code, but my point is that, at the
end of the day, I want to see one name on that package of who is responsible
for it, I do not want to see a "group" name on it. at any one point of time,
there should be a person responsible for that piece of code if at all 
possible.

>Also, if there is this much code ownership going
>on, then you are bound to get divergence in style, further contributing
>to people being unwilling to look at, let alone work on, other people's
>code.
>

not really, this is what code standards are for. each group will agree on some
standard and convention and use that before they start implementation. 
this is a common thing that is done. (at least I hope so)

>I quite understand that a lot of programmers feel as nabassi does,

if many feel like me, then there must be something right about it :)

> but
>for me, one of my absolute requirements in a software project, is that
>this attitude cannot be permitted, and I could not have people with this
>attitude working on projects that I was managing.
>

I also would also work on a project where people are not held accountable for
their work. I've seen projects like these, every programmer hides behind the
"team" or the "group" name, no one is resposible for anything, no person
name is on any thing. a great place for laxy programmers to hide for
years in there. this is not for me.

>It's a matter of style, but I can certainly tell you that even though you
>can't really imagine that it works, my experience is that the "egoless"
>style in which people do not own the code they write, gives MUCH better
>results than the code ownership model -- you should try it some time!
>

egoless programming does not mean one should not "own" their work. 
you can have both togother. egoless means being open to others views, being
open to design changes, to changing your pakcage interface to accomedate new
design changes in other parts of the system, being open to describing to
others your work, being open to having code reviews and accepting positive
critic on your work. but one still "owns" the work they are working on !

I dont thing I can add more to this, I think I explained my views on this as
much as I can. at the end, every one is free to use the system they feel works
best for them.

Nasser