Shmuel wrote: <begin extract> It's corrupted by human beings making sloppy and undocumented code changes, which accrue over time. Any single change doesn't do much damage, but the cumulative corruption can be massive. </end extract>
This happens, but 'undocumented' is often not the problem. Many COBOL shops are meticulous about noting changes as they are made IN the affected source programs themselves. It is the character of this documentation that makes it problematic. It addresses changed functional requirements instead of processing strategies. One reads, say, that the widget tax rate for West Virginia was chang ed from 2.25% to 2.65% on 2005 October 20 by Ætheltred ap Smith and DdU Caradog; but one is not told how or where, often in several places, this change was made. Moreover, such changes are usually made and procedurally rather than declaratively, by changing a line of code instead of updating a table element. The cumulative effect that Shmuel has already emphasized is disastrous. Even systems that once had explicit designs and processing strategies, and they are few, dissolve into a formless and incoherent welter of ad hoc changes. Worse, there are no easy remedies. In particular, changing programming languages seldom helps unless the people using them are changed too and everything is redesigned. C functions, say, turn out to be COBOL programs tricked out with brackets, braces and semicolons. John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
