From: holger@vmars.tuwien.ac.at (Holger Reusch (Dipl. ALF in spe))
Subject: Re: The inevitable question
Organization: Technical University Vienna, Dept. for Realtime Systems, AUSTRIA
Distribution: usa
Date: Tue, 28 Jul 1992 11:23:36 GMT

In the last years, I took some measurements of coding speed, error finding
speed and error correction speed from several programmers who worked in a
mixed C++/COBOL environment.  From there (and from personal experience) I got
some new insights in the problems addressed here.

In <Bs2r39.Hot@snuffy.wa.atk.com> mluders@snuffy.wa.atk.com (Matthew_Luders) writes:
>I'm not sure what you mean when you say "the hallmark of COBOL systems is
>maintenance."  Are you saying COBOL is such an easy-to-read language that
>programs written in it are easy to maintain?

Definitely yes.  Especially if programs were written by someone else, the time
until a programmer knew what was "going on", was about 20% less for COBOL than
for C++.  Of course, some coding rules were enforced for both languages
(no ALTER, GOTO DEPENDING ON, or CORRESPONDING for COBOL, no pointer tricks or
cryptic variable names in C++)

>Or that most of a COBOL
>programmer's time is spent doing maintenance?

Not necessarily, but since about 80% of total existing LOCs worldwide are
written in COBOL (admittedly, this percentage is falling), a lot of programmers
are necessary for maintaining the applications.

>If the former, then I'm
>afraid I have to disagree.  I find that a well-written C program is
>easier to maintain than a poorly-written COBOL program.

Hear, hear.  Now what if I say that I find a well-written COBOL program
easier to maintain than a well written C program?  Ease-of-maintenance is
primarily proportional to the cleanness of the code.  Messy programs are hard
to maintain, no matter the language.

Again, my findings are that equally well written COBOL code is a bit easier
to maintain than C (or C++) code.  This might be true to the lower statement
per character ratio (Ever tried to plot stmt/char vs. error correction time
for several programming languages?  I did, and I found a 85% correlation.)

>Again, I find
>that the structure of the code and the choice of variable and module names
>has a much larger impact on maintainability than the language itself.

D'accord, but I uphold my stmt/char reservation.  What's the fundamental
difference between operator symbols or keywords and variable names?  IMHO, a
full PERFORM statement is easier to read than a 'for'.  I don't say that it's
as elegant, but it's easier to decypher.

>If you meant that most of a COBOL programmer's time is spent doing maintenance
>rather than developing new programs, then I believe you are correct.  The
>question is, why?  I believe it's partly due to ever-changing requirements
>caused by changes in the business processes that the COBOL programs support,
>and partly due to the horrible condition of the programs themselves.  I've
>seen scores of COBOL programs that violate just about every principle of good
>software design you can think of.  This is one reason why they last as long
>as they do.  Companies depend on these programs for day-to-day financial
>record keeping, so they can't just get rid of them.  Replacing them is
>expensive and disruptive.

To say rewriting a typical 1.5 MLOC COBOL installation is like saying that a
supernova is "bright" :-)  The complete life-cycle would consummate hundreds
of man-years and would cost $600K to $1M.  That's too expensive just to hold
the status quo.  You can do a *lot* of maintenance for $600K!

>Why are the programs in such bad shape?  Three possible reasons spring to mind:

>(1) Many of them were written 15-20 years, before the importance or principles
>    of structured design were well-known or followed.

Many software houses have no coding standards and are leaving the dirty work
to underpaid students who were never taught the rules of clear structuring.

>(2) The people that wrote these programs had backgrounds in accounting or
>    business management, not computer science or electrical engineering.

Thanks to COBOL, even such people can read programs, understand them and
do some good coding *IF TAUGHT HOW TO DO IT*.  Unfortunately, many project
leaders don't employ adequately skilled programmers.

>    Actually, this seems to be true even today.  In fact, this is probably why
>    COBOL is under the alt heading instead of comp.lang with the other
>    languages.  I wonder how many COBOL programmers even know of the existence
>    of the Internet?

Ths problem lies deeper.  COBOL is mostly used on finance & business sites.
These sites use to be quite paranoid WRT to external intrusions (hackers,
worms, ...).  The Internet, while being one of the largest existing networks,
is not known for its security (Would you transmit your credit card # over the
Internet? :-).  Furthermore, commercial traffic is prohibited for the NSFnet,
the Internet backbone.  Hence, the big mainframes of banks and insurances,
where COBOL development takes place, are not connected.  I tried to pursuade
the management where I worked to connect to the Net, but they declined due to
security concerns (Partly I can understand them, ever read the RFCs?
[Followups to this paragraph to alt.internet]

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

If I find a programmer doing a quick & dirty patch in a piece of code I give
him, that merits the cat-o-nine-tails (for him, of course :-).   Again, no
language problem.  In fact, a management problem.

>There is a bright side.  For all the criticism that COBOL gets from software
>engineers, it is possible to write structured, readable, maintainable code with
>it.  Its record and field handling capabilities make it well-suited for
>creating reports, which is probably what it's used for the most.  But the fact
>that a program is written in COBOL certainly does *not* guarantee (or even
>improve the chances) that it's maintainable.  In fact, you could argue that
>there are elements of COBOL that tend to make programs written in it *less*
>maintainable (e.g. the lack of local variables).  Some of these problems were
>addressed with the release of COBOL-85 (e.g. the addition of the end-if and
>evaluate statements), but I don't know how widely COBOL-85 is being used yet.

IMHO, the most important point that speaks for using COBOL in a commercial
environment is *standardized record-i/o*.  No other language has indexed file
processing defined as part of the language.  Ever tried to migrate a program
(C++, in my case) from one platform (with an obscure I/O toolbox) to another
platform (with an equally obscure, but subtly different, toolbox?)?  Yuck!

COBOL 85 is the language of choice for new programs.  I don't know of old
code being re-written in COBOL 85 (Would be a bad idea, IMHO).

>I'd be curious to hear other people's opinions on these topics.

Here are mine.  I'm curious about others, too.  Furthermore, I'd like to know
how much COBOL experience people appending to this have (As a start to this,
I've designed, written and tested about 20KLOC COBOL over a span of 3 years
and I have held COBOL introductory classes for 2 years).

-- 
| Holger Reusch                             |
| Technical University of Vienna, Austria <-+--- No kangaroos here,
| Dept. for Real-Time Systems               |    sorry!
| holger@vmars.tuwien.ac.at                 |