home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / alt / cobol / 332 < prev    next >
Encoding:
Text File  |  1992-07-27  |  3.8 KB  |  75 lines
  1. Newsgroups: alt.cobol
  2. Path: sparky!uunet!nwnexus!snuffy!mluders
  3. From: mluders@snuffy.wa.atk.com (Matthew_Luders)
  4. Subject: Re: The inevitable question
  5. Message-ID: <Bs2r39.Hot@snuffy.wa.atk.com>
  6. Organization: Alliant TechSystems Inc.
  7. References: <1992Jul25.060022.9237@uwm.edu> <1992Jul25.154243.19607@cs.unca.edu> <EMERY.92Jul27111003@Dr_No.mitre.org>
  8. Distribution: usa
  9. Date: Tue, 28 Jul 1992 01:06:44 GMT
  10. Lines: 63
  11.  
  12. emery@Dr_No.mitre.org (David Emery) writes:
  13.  
  14. >The hallmark of COBOL systems is maintenance.  That's because they
  15. >tend to last a very long time.  A language that does not
  16. >provide/support software understandability and maintenance is not an
  17. >adequate replacement for COBOL.
  18.  
  19. I'm not sure what you mean when you say "the hallmark of COBOL systems is
  20. maintenance."  Are you saying COBOL is such an easy-to-read language that
  21. programs written in it are easy to maintain?  Or that most of a COBOL
  22. programmer's time is spent doing maintenance?  If the former, then I'm
  23. afraid I have to disagree.  I find that a well-written C program is
  24. easier to maintain than a poorly-written COBOL program.  In fact, I find
  25. that the structure of the code and the choice of variable and module names
  26. has a much larger impact on maintainability than the language itself.
  27.  
  28. If you meant that most of a COBOL programmer's time is spent doing maintenance
  29. rather than developing new programs, then I believe you are correct.  The
  30. question is, why?  I believe it's partly due to ever-changing requirements
  31. caused by changes in the business processes that the COBOL programs support,
  32. and partly due to the horrible condition of the programs themselves.  I've
  33. seen scores of COBOL programs that violate just about every principle of good
  34. software design you can think of.  This is one reason why they last as long
  35. as they do.  Companies depend on these programs for day-to-day financial
  36. record keeping, so they can't just get rid of them.  Replacing them is
  37. expensive and disruptive.
  38.  
  39. Why are the programs in such bad shape?  Three possible reasons spring to mind:
  40.  
  41. (1) Many of them were written 15-20 years, before the importance or principles
  42.     of structured design were well-known or followed.
  43.  
  44. (2) The people that wrote these programs had backgrounds in accounting or
  45.     business management, not computer science or electrical engineering.
  46.     Actually, this seems to be true even today.  In fact, this is probably why
  47.     COBOL is under the alt heading instead of comp.lang with the other
  48.     languages.  I wonder how many COBOL programmers even know of the existence
  49.     of the Internet?
  50.  
  51. (3) COBOL programmers (like programmers everywhere) are often under pressure
  52.     to make changes to code quickly.  This can lead to "quick-and dirty"
  53.     patches that are not well-integrated with the basic design of the program.
  54.     Over time, this leads to code that is a convoluted mess of patches on top
  55.     of patches on top of patches, ad nauseum.
  56.  
  57. There is a bright side.  For all the criticism that COBOL gets from software
  58. engineers, it is possible to write structured, readable, maintainable code with
  59. it.  Its record and field handling capabilities make it well-suited for
  60. creating reports, which is probably what it's used for the most.  But the fact
  61. that a program is written in COBOL certainly does *not* guarantee (or even
  62. improve the chances) that it's maintainable.  In fact, you could argue that
  63. there are elements of COBOL that tend to make programs written in it *less*
  64. maintainable (e.g. the lack of local variables).  Some of these problems were
  65. addressed with the release of COBOL-85 (e.g. the addition of the end-if and
  66. evaluate statements), but I don't know how widely COBOL-85 is being used yet.
  67.  
  68. I'd be curious to hear other people's opinions on these topics.
  69.  
  70.  
  71. Matt Luders
  72. mluders@snuffy.wa.atk.com
  73.  
  74. These are my opinions only, not those of Alliant Techsystems Inc.
  75.