From: mluders@snuffy.wa.atk.com (Matthew_Luders)
Subject: Re: The inevitable question
Organization: Alliant TechSystems Inc.
Distribution: usa
Date: Tue, 28 Jul 1992 01:06:44 GMT

emery@Dr_No.mitre.org (David Emery) writes:

>The hallmark of COBOL systems is maintenance.  That's because they
>tend to last a very long time.  A language that does not
>provide/support software understandability and maintenance is not an
>adequate replacement for COBOL.

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?  Or that most of a COBOL
programmer's time is spent doing maintenance?  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.  In fact, 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.

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.

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.

(2) The people that wrote these programs had backgrounds in accounting or
    business management, not computer science or electrical engineering.
    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?

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

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.

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


Matt Luders
mluders@snuffy.wa.atk.com

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