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

[tconiam@aol.com (TConiam)]

>My own personality is most comfortable with the egoless style, and
>that's how I prefer to do things.  So I mostly agree with Robert here.

So do I, although it is at some times a very hard personal internal battle when
it comes to having someone else find faults or bad assumptions in the code I've
created.  However, once all is laid out on the table I learn from it and try to
avoid the same mistakes.  I also never blame the individual who found the
fault, in fact I let them know that I appreciate their insight.

>
>Example: I'm working on a certain package, and I decide that one of the
>exported procedures is poorly named, so I want to change the name.  It
>seems to me that the best thing is for me to do a global search and
>replace, and change all the call sites (assuming the source control
>system doesn't lock me out of some file).  But I've worked with some
>people who are annoyed at that.  They prefer that I send them e-mail,
>saying "I've changed XYZZY to Do_Good_Stuff, please fix the call sites
>in 'your' code."  To me, that seems inefficient, and disruptive, since
>it leaves things in an inconsistent state.  In fact, it might well cause
>me to decide that the change is too costly, and leave the bad identifier
>alone, thus damaging the long-term quality of the code.
>

In this situation we have always brought the group together and had a short
discussion about the global change.  If the group agrees, it is assigned to one
person to accomplish, generally the one suggesting the change, this assures
consistancy and responsibility for it's accomplishment.  If the group feels it
is not necessary, it is not done, this prevents unecessary or arbitrary
changes.

Todd Coniam