Book "python programming patterns". anybody read this??

[Peter Milliken]

G'Day Cliff,


"Cliff Wells" <logiplexsoftware at earthlink.net> wrote in message
news:mailman.1009574494.4804.python-list at python.org...
> On Mon, 24 Dec 2001 06:59:21 +1100
> "Peter Milliken" <peter.milliken at gtech.com> wrote:
>
> > Generally the standard of maintenance programmer is just
> > not as good as developers (otherwise they would be developing, wouldn't
> > they? :-)) and so it is a well recognised tenant that I attempt to
follow
> -
> > code for the lowest common denominator.
>
<snip on the bitching :-)>

Sorry to hear of these experiences, I guess we all run into this kind of
situation sooner or later :-).  Good luck with unravelling the mess.

> Anyway, my point is, I think your statement is unfounded.  There are
> undoubtedly cases where what you said is true, but to assume it's the
> common case is wrong - especially when you consider that many people
> (myself included) learned to program by developing applications, so the
> quality of coding in those apps is poor (I would probably cringe if I were
> to review code I wrote 10 years ago - some poor sod is probably cursing me
> right now as he tries to decipher some mess I wrote =)
>

I am an Electrical Engineer with a single semester of Fortran and Basic :-).
The rest is self-taught, on the job training that spans (depending how you
count it) at least 20 - 25 years. We all "cringe" when we think of our
earliest efforts - I still produce awful code when I make the mistake of
thinking I can just bash out a program off the top of my head - personally,
I have to sit down and think the entire application through and do a design
and requirements analysis (not in that order :-)) otherwise I end up with a
poorly designed and coded mess :-). Perhaps others can say they produce
works of art off the top of their heads without design that they would be
proud to have other programmers review - I can't.

Most of us, at some stage, spend our early introduction in a maintenance
environment (mine was maintaining 24 6" thick volumes of listings of
assembler code which another company had been hired to provide comments for,
they ended up with approximately one comment per listing page - back in '79,
I think it was :-)). I am currently work in a maintenance environment. So
sometimes you tend to make statements that are a bit sweeping. But I still
stick by the general statement that typically, the majority of programmers
in maintenance roles would not be there if they had a choice. I am an
exception, I have a choice, but my choice was to get out of defence - and to
erase a "stigma" of 20 years in an industry isn't easy! :-)

> Besides, applications are often written without  a good specification (or
> only a very basic one) so the developer is left winging it, adding
> features, learning new toolkits, etc, until the original architecture is
> obscured beyond comprehension.  Take a look at many of the open-source
> projects around and you'll often find that one of the first things
> "maintainers" do upon acquiring a system is recode large portions of it to
> make it more readable/maintainable, etc.
>

Yes, I have a poor background to comment here and this may sound (almost
certainly! :-)) overly harsh, because I spent most of my work experience in
the defence industry. But to me, "pressure to market", "no time to
analyise", "no time to design", "customer doesn't know what he wants, so we
have to wing it" - are at the end of the day just excuses for the fact that
*all* the people involved in the project can't be brought around to the
concept/idea that you should sit down and plan the project step by step and
not proceed to the next until the previous is complete i.e. sit down with
the customer, analyise the requires - protype if necessary, but get them
nailed down and worked out until the customer is happy that he knows what he
wants!.  Then the programmer should sit down and use the analsysis to
generate a design (documentation! ugh, how many programmers want to spend
their life doing documentation! - there is always some excuse not too! :-)
"gee, if we did that then the competition would beat us to market and we
wouldn't have a job" - true I am sure in some cases but I doubt this is true
for the majority of cases/projects!). Then the code can be generated from
the design. Overally idealistic I am sure, but that is my opinion :-)

People talk about the "software crisis" - the only crisis I have seen (in my
experience :-)) is the one that your typical programmer doesn't want to do
"paperwork" - all he/she wants to do is generate the next coding
masterpiece. A formal analysis means paperwork, a good design means
paperwork (and what is worse - others have to be able to read and understand
it! :-)). But most programmers want to cut code - nothing else :-). Your
point about the open source projects proves the point. Nobody bothered i.e.
wanted to, sit down and work out the requirements properly - that would have
taken "unnecessary time", "we know what we want - lets start coding!" :-)
Hence others come in after the fact and re-write the entire thing - a very
expensive exercise!

Peter

> That said, I don't disagree with your tenant of coding for the LCD.  While
> not always possible, it's good to keep in mind when one is tempted to
write
> "clever" code =)
>
> Regards,
>
> --
> Cliff Wells
> Software Engineer
> Logiplex Corporation (www.logiplex.net)
> (503) 978-6726 x308
> (800) 735-0555 x308
>