Defending the Python lanuage...

Peter Milliken peter.milliken at gtech.com
Tue Feb 5 16:54:01 EST 2002


G'Day Cliff, I won't reply to the earlier email in the thread - that one is
finished IMO - thanks for the insight into how you work, it gives me
something to "chew" over :-)

"Cliff Wells" <logiplexsoftware at earthlink.net> wrote in message
news:mailman.1012863309.22323.python-list at python.org...
> On Tue, 5 Feb 2002 08:53:27 +1100
> Peter Milliken wrote:
>

[snip]

> > code. If the individuals involved approach the problem with the correct
> > frame of mind then I have never, ever seen inspections/reviews fail! It
> is
> > only when it is not tackled with the right sort of commitment that it
can
> > appear not to work.
>
> Exactly.  I still venture that they won't ever be "tackled with the right
> sort of commitment" because it's no fun having to read other people's
code,
> and lack of enthusiasm always seems to win over policy and "requirements"
> in the end...
>

Not so, in my experience, if you get the code reviewed before it is compiled
or (at very least) before it is unit tested (which is my preference) then
there is a real incentive for reviewers to look at it because they *know*
there are bugs to find. Incentive in code reviews dwindles towards zero when
you "know" that the author has already (supposedly) "tested it to death"
:-). Sometimes if you know the programmer is bad enough there is still
incentive, but then you have to battle the frustration of reviewing
absolutely gross code :-)

My experience ( :-) ) is that if reviews (or inspections, whatever you want
to call them) are carried out with diligence then the project is successful,
the unsucessful projects had the (one of) symptoms of either no reviews or
reviews that were paper only i..e. they satisfied a QA audit and that is it
:-). Of course, this was from a background of SRS, SDD (Preliminary and
Detailed), Test Plan, Test Documentation etc etc etc ad nauseum. In the
"commercial" world of requirements discussion with the customer and then
informal talks between programmers and then code, there aren't too many
steps to review! :-)

>
> > I get somewhat frustrated sometimes when I look at yet more attempts to
> > solve the same problem when I believe there are already workable
> solutions
> > (this will, I am sure be disputed :-) but is only a statement based upon
> > personal experience :-)). I think it is most likely the lack of
> > self-discipline (in programmers, not themselves) that caused the authors
> to
> > look for alternative methods - also, the fact that they needed something
> new
> > to write about otherwise they wouldn't be able to publish a book! :-) I
> must
> > admit that in a weak moment, I purchased a copy of Extreme Programming,
I
> > read it on the train one evening (not the whole book! :-)) and saw
enough
> to
> > make me put it where it is now, on my shelf gathering dust :-).
>
> I haven't read much beyond magazine articles regarding XP myself, but I
> suspect they realize the futility of traditional approaches (not that the
> approaches wouldn't work... people just won't use them which amounts to
the
> same thing) and tried to develop new approaches that mirror what
successful
> developers do already.  For example, the "make one to throw away" approach
> is something that most of us do already (or should, I've had _very_ few
> projects where the spec was so perfect and my understanding of the tools
so
> complete that I've gotten it perfect the first time), they just made it
> into a "formal" design phase.
>

Interesting that there is this "acceptance" that the traditional approaches
are futile because people just won't use them. I don't agree with that
philosphy, a similar argument would be "lets decriminalise burglaries
because people persist in doing them" :-) BTW, I appreciate your
qualification on this one, many others would have just said that
"traditional methods" don't work :-). Of course, if you can get people to do
them then they work extremely well - else why would we have so many books
advocating them? (plus I have seen them work extremely well :-)). I remember
my introduction to reviews/inspections - the project manager said do them or
find a new job - gave us great incentive to learn how and do them with
enthusiasm :-).

So, Rony, assuming we haven't bored you to death by now - what are managers
going to do about the above situation? Cliff and I (seem) to be in agreement
that traditional methods would work if they were accepted by the
programmers - so how do you plan to accomplish this? :-)

So we get back to the basic fact that our industry is undisciplined and
hardly "professional" :-) Broad sweeping statements, I know and there are
obviously many exceptions, but as a generic, general statement it seems to
be true.

Thanks for the dialog Cliff,

Peter

> --
> Cliff Wells, Software Engineer
> Logiplex Corporation (www.logiplex.net)
> (503) 978-6726 x308  (800) 735-0555 x308
>
> "Then with your new power you'll accomplish all sorts of cool stuff
>  in no time, and We'll All Be Sorry.  At that point you can either
>  gloat a bit, and then relent, or go ahead and send the robot army
>  after us." - Quinn Dunkan
>





More information about the Python-list mailing list