[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PG: Hackers and Painters

On Fri, May 16, 2003 at 11:27:12AM -0400, Jeremy Hylton wrote:
> On Wed, 2003-05-14 at 15:13, Andrew Pimlott wrote:
> > Common code ownership, on the other hand, I find a generally bad
> > practice.  I really don't see how a piece of evolving code can
> > retain any conceptual integrity if nobody feels responsible for
> > it--and I've seen nice code without an active owner decay many
> > times.  I don't think that "refactoring" can fix this, since there
> > is no way that Joe bug whacker will take the time to understand the
> > original design.
> Several people have expressed a similar sentiment.  I don't agree with
> the premise that common code ownership means that no one feels
> responsible for the code.  In fact, the opposite should be true; if
> everyone owns the code, everyone should feel responsible.
> If no one person owns the code, then it is everyone's responsibility to
> repair broken code and improve what exists.

I said after the part of my message you quoted that XP folks don't
put much stock in design.  I think what you wrote demonstrates what
I meant.  You see value in fixing bugs, optimizing, adding features,
etc.  But you don't seem to see value in the sort of conceptual
unity that is the product of a single (sometimes, but not normally,
more) mind.  My experience has taught me that this is of immense
practical value.  (Arguing the relative values of such things in a
meaningful way is probably impossible without more common ground.)

I absolutely did not mean to suggest that people should keep their
noses out of other people's code.  In a team, everyone should feel
responsible for the overall quality of the software and be free to
chase issues into other people's code, make changes that ripple
across module boundaries, and browse the codebase as bedtime

But it is unrealistic to expect that everyone on the team will
understand the thinking behind a piece of code better than a primary
owner.  If I check in a perfectly correct bug fix to your code, it
is still likely that I will erode its integrity.  I will overlook
some convention you were using or, I will not fix the problem in the
same way or even the same place as you.  After several such changes,
you will no longer have the mastery over the code that came of
creating it with your own hands.  The code will work better than
before, but in the long term it will suffer.

It is better to propose a fix to you and let you check in a version
you were happy with--or tell me I have the wrong idea all together.