A question of Style, was: SPUG: Sort an array question

Fred Morris m3047 at inwa.net
Sun Dec 29 12:48:52 CST 2002

Michael R. Wolf wrote:
>I just got finished reading "Extreme Programming Explained: Embrace
>Change" by John Beck.  This code frag brings up an important point he
>makes in the book about collective ownership of code, important for
>me, that is.   I can't tell you how any times I've run across code
>like this, and wished I could change it.  I especially hate code like
>In the past, I've always felt disempowered by the ownership issues.
>My insights had been prevented from increasing the quality of the
>collective knowledge (say "code base").  With collective code
>ownership, I'm completely empowered to share my wisdom by rewriting
>any of the code.

In the only CMM Level 3 certified shop I've ever had the distinct and
unequivocal pleasure (the one and only shop I offered to give a written
letter of recommendation to if they asked) of working in, this issue was
not only one of the major unresolved philosophical questions, but a
practical headache for coders and release managers alike.

The scoping of changes can rapidly get out of hand. For instance you may
find a constant which is globally declared and imported everywhere which is
only used in one place... to prove this (to yourself) you check (readonly)
all kinds of things out of the code management system and comment it out.
Now: do you check all of those modules back in or not? It's actually a
minor change, but in terms of the metrics utilized it's a major one (look
at all of these modules which have been changed!). Even changing i,j,k,l to
something more meaningful can result in an arduous code review: it's not
only the code you changed (presuming that you can prove objectively that
the scope is limited), but the possible impact on any tools which have been
developed to do various things. Writing documentation (where the existing
documentation says something like "document this") can even be considered a
scope change, albeit a necessary one.

It's not that you simply don't do these things, it's that it's a headache
for everyone; which probably means less of it gets done than "should" get
done thinking of things in a long-term, high-level way. I have yet to find
an SE manual anywhere which addresses this maintenance problem in a
rational and deliberate fashion (with special consideration for systems
which were not originally developed under the same configuration management
strictures under which they are being maintained).

If there's a lesson to be learned, it's that the longer this stuff stays in
the code the more of a headache it is to do something about... and you
don't know what's going to be part of a larger system someday, or how long
that system will be maintained. (In my current "day job", one of the things
I do is support commercially released software which has my name in the
change logs from at least 15 years ago. Gaaah! Do you have any idea how
many hands have been in it in the interim?? There's another lesson here:
you may not know what piece of code will still be around in 15 years when
you write it, but if any of it is any good then 15 years down the road
somebody, somewhere, will be maintaining some of it.) (I hear rumors that
there are still PDPs stalking the earth...)

>AND (and this is a huge bonus) I'm graced by the
>wisdom of others.  None of us is as smart as all of us.  I've written
>lots of code that gave someone else enough of a view into the problem
>that they were able to take it one (or three) steps better than what I
>originally wrote.  (Of course, there's an obligation to change code
>for the "better", not merely for my pettty "preferences".  That's a
>team responsibility.  In fact, it's put into a check/balance situation
>by the pair-wise programming.  If *I* think it's a great idea, but I
>can't convince a partner, then I should either take their word for it
>or rethink my motivations.  Of course this all goes down the tubes
>unless there's mutual trust and respect.  I've assumed that as a
>given.  Nothing's gonna' work without it.)

I haven't read any books on "XP". But this is the sort of thing which
reinforces my general impression that XP is an item or component practice
and not a software engineering methodology.

Needless to say peer review, no matter how it is fostered, is a key
practice and IMO&E probably the chief technique for producing that sort of
holographic agreement^H^H^H^H^H^H^H^H^H consensus on "how things get done"
which is found in measurably successful shops: exactly what the process is
(or supporting tools involved) is far less important in the grand scheme of
things than that there is a defined and universally recognized process and
that peer review is part of it.

(Who wants to get into a jump plane with someone who's too macho for a "pin

ObPerl: So how does peer review rationalize with TMTOWTDI? Does TMTOWTDI
lead to more opportunities for improvement, or does it necessitate it? Do
we just take the maxim that TMTOWTDI as the equivalent of "Hey, I like the
way those gloves look (and I assume they're warm, because it's cold out
here!)"? Is there, practically speaking, more than one way to implement
Perl5? Isn't the fact of one and only one implementation of Perl5 a result
of peer review?

>[from another post]
>In "Peopleware", DeMarco and Lister mention[...]


Who's Lister? I thought DeMarco went back to psychotherapy and left Yourdon
to carry on the good fight. :-p

Also off-topic, I found LARC's systems engineering handbook on-line (large


(and check out the LIDAR stuff)


Fred Morris
m3047 at inwa.net

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
     Seattle Perl Users Group (SPUG) Home Page: http://seattleperl.org

More information about the spug-list mailing list