From: mluders@snuffy.wa.atk.com (Matthew_Luders)
Subject: Re: The inevitable question
Organization: Alliant TechSystems Inc.
Distribution: usa
Date: Wed, 29 Jul 1992 18:25:00 GMT

alawrenc@sobeco.com (Andrew Lawrence) writes:

>they are comparing apples and oranges.  Just for the record.  I have been
>programming professionally in assembler and machine languages since 1967,
>COBOL since 1970, RPG-II, III & 400 since 1976, BASIC since 1981, C and PASCAL
>since 1984, not to mention the dozen or so other languages I used for various
>project.

First, let me commend you for continuing to learn new languages throughout
your career, especially languages as different as COBOL and C.  I wonder,
however, if you are the exception rather than the rule.  Most programmers seem
to know several languages, but they are all fall into either "business"
(COBOL, RPG-III, DB2, JCL, etc.) or "engineering" (C, Pascal, Ada, FORTRAN,
etc.).


>Maintainability
>is impacted by the quality of the documentation and how well the original
>design was structured and the programs written.  Again, irregardless of
>language.

I couldn't agree more.


>Structured programming has been with us since 1972.  Before that we used a
>technique called modular programming which was the same thing defined
>less formally.  Before that smart programmers designed and wrote their
>code that way because it worked and was maintainable.

I know that the *principles* of structured programming have been around for
20 years, but how quickly were the principles adopted and how widely are they
followed?  Even today, I know COBOL programmers who see nothing wrong with
putting hard-coded data (that is certain to change) directly into their code,
or using non-returning transfers of control (i.e. gotos), or letting control
simply fall from one paragraph to another.  How widespread are these practices?
Conversely, how widely have structured programming principles been adopted by
COBOL programmers?  Can anyone shed some light on this?


>Give me professional programmers, who
>know about standards, walkthroughs, documentation and coding efficienty.

I have never been given a set of coding standards by management (although I
religiously follow my own), and have never taken part in a structured walk-
through.  Are these common practices?


>In reality bad code is the result of bad system management.  The
>project manager is the one who decides whether or not to adhere to
>programming standards, not the programmer.

Yes and no.  Bad code is the result of bad programming practices.  A good
programmer will adhere to good programming standards, regardless of what the
project manager decides (unless he is forced to do otherwise).  I'm not at all
convinced that programming standards can force a lousy programmer to write good
code.  The best they can do, I think, is to keep him from writing horrible
code.


>In the past I've sent
>more than one program back for a major rewrite because the programmer
>was sloppy and I've fired programmers who thought standards were for
>others.  Again the language involved has no importance.

Good for you!  It's encouraging to hear that there are people in positions of
power that understand the importance of well-written code, and the dangers of
sloppy code.  We need more managers like you.  The only thing you need to be
careful of is *which* standards you're going to enforce.  Arbitrary standards
are even worse that no standards if they force a programmer to do harmful things
to his code.  You should be able to make a compelling argument for any practice
you're going to enforce as a standard.  "That's the way we've always done it"
or even "that's the way most people do it" is not a compelling argument.

Standards need to make sense.  Actually, I find that standards seem to have the
same problem as that of advice in general: "wise men don't need it, and fools
won't heed it."  In other words, good programmers don't need to be told what
standards to follow because they have seen the effect that certain practices
have on the maintainability and efficiency of their code, and have learned from
it.  As you said, "Before [structured programming] smart programmers designed 
and wrote their code that way because it worked and was maintainable."  Bad
programmers, on the other hand, will probably always be able to find some way
to mess up their code that was not specifically forbidden by the standards.


>Very, very few.  Most programmers, not just COBOL, go to work in the
>morning, work at their assigned tasks throughout the day, and go home
>at the end of regular business hours.

How robotic.  Personally, I don't think that's sufficient.  I think that part
of being a professional is taking an interest in the tools you use to do your
job.  A elements of a computer language are to a programmer what a hammer and
chisel are to a sculptor.  Each should know his tools intimately--what they can
do and how to use them correctly.


>>(3) COBOL programmers (like programmers everywhere) are often under pressure
>>    to make changes to code quickly.  This can lead to "quick-and dirty"
>>    patches that are not well-integrated with the basic design of the program.
>>    Over time, this leads to code that is a convoluted mess of patches on top
>>    of patches on top of patches, ad nauseum.

>Again, this applies to any programming environment.  Its a management
>problem, not a language or programmer problem.

Agreed.  The question is, how does a programmer tell a manager that he's making
a bad decision?  In fact, the problem is more general: how does any person in
a corporate hierarchy tell a "superior" that they're doing something wrong?
There seems to be an awful lot of unspoken pressure to keep quiet.  And after
all, what has the employee got to gain?  So what if the company is wasting
money?  I'm starting to think that this phenomenon is one of the single biggest
reasons why American companies keep falling behind in the world economy.

Anyway, you made some excellent points.  Thanks for responding to my post.


Matt Luders
mluders@snuffy.wa.atk.com

These are my opinions only, not those of Alliant Techsystems Inc.
Newsgroups: alt.cobol