From: rca@csd4.csd.uwm.edu (Robert C Allender)
Subject: Re: The inevitable question
Originator: rca@csd4.csd.uwm.edu
Reply-To: rca@csd4.csd.uwm.edu
Organization: University of Wisconsin - Milwaukee
Distribution: usa
Date: Thu, 30 Jul 1992 02:08:03 GMT

From article <Bs5xtp.Fnv@snuffy.wa.atk.com>, by mluders@snuffy.wa.atk.com (Matthew_Luders):
 
> 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.).
> 
     It is difficult to find a magazine that deals with programming
that doesn't deal with C, Pascal, or Modula-x. Things _are_ going in
that direction.  In the same breath it is true that the vast majority
of DP is done with COBOL.  What may have been the exception is going
to end up being the rule.  

 
> 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?

    In my undergrad years, I took a few semesters of COBOL and went to
a tutor on the side because I wanted to know more than just the
basics.  I was disappointed when my tutor began explaining that all
the structure that I was learning isn't what I was going to need when
I got into the "real world."  He was a programmer by profession and
said that his shop used all the goto's needed to make the darn thing
run by the due date.  :-(

    My first experience as a programmer was very similar.  I studied
printouts of programs and did some maintenance, and it was TOTAL
patchwork.  If the system ever needed to be reworked, I sure as heck
wouldn't want to be around.

   The scientific languages are taught and used quite differently (I
use "scientific" in the same context as you do, meaning Pascal, C, and
the Modula languages).  Object-orientation (C++, actor, smalltalk,
Ada, etc.) and code reusability are major issues and allow code to be
efficiently written, read, and maintained.  If COBOL would be taught
this way, um...If COBOL _COULD_ be taught this way, I think some of
our entry-level maintenance programmers would be pounding the
pavement.


> 
> 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?
> 
     Again, the above pertains.

> 
>>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.
> 
       My $0.02 worth is this:  I've had managers who accepted bad
code.  I've never had one who rejected good 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.
> 
     Standards are laws.  Put federal and state laws in plain English
and they make good sense.  Chances are that ordinary people who want
to live peacefully with one another would follow many of our laws even
if they were not written out.  For those who would be detrimental to a
peaceful co-existence, we write out the laws in detail so that they
too can live peacefully with others.  The same thing goes for
programmers, whether it's now or in the 50's.

> 
> 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.

    If only everyone *did* think this way.  

> 
> 
>>>(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.

     Fear of a lost job in such a situation *is* a factor.  A phrase
has been coined regarding it.  "Selling out" basically means that if
you're good looking but believe that being a stripper is wrong, and if
you become a stripper anyway because the pay is great, you've "Sold
out."  I've seen a *lot* of graduate admission applications that
involve essay questions like "Describe a business situation that
tested your morals."  This type of question (hopefully) makes people
realize the importance of maintaining what *you* know to be correct,
even if it means going over the manager's head and risking your job.
Selling out is about as demeaning and frustrating as I can
imagine...don't do it.

> 
> These are my opinions only

    ditto.


Rob Allender







-- 




Newsgroups: alt.cobol