- Apollo
- Technology and the world
- Esso Business Systems
- Exxon to Oglethorpe
- Software development
- Management trends
- Era observations
Software development
In the early Wild West era, software processes, tools, reference books, and training were scarce. I learned from the IBM COBOL manual and rushed frequently into Ed’s (from Esso) office to ask questions. Most of my knowledge acquisition came through experiences—both good and bad. Owing to his quiet style Ed was difficult to communicate with, but his experience made him an invaluable early mentor to me.
In the Exxon business group, there was a programmer who transferred in from technical systems. His technical programming had been in Fortran,15 so he wrote his first business application, a payroll system, in COBOL, but used Fortran-like data names. Fortran programmers were accustomed to using data names like “EMPRT2” because of language restrictions,16 rather than COBOL data names like “Employee-Pay-Rate2.” His COBOL programs using Fortran data names caused untold maintenance headaches when he moved on. More Wild West.
One infamous, insidious, and even dangerous COBOL statement epitomizes the nature of this era—the ALTER statement. Think of a program statement—Go To CALC-Pay-Status. Okay, so far. Now comes the fun part. Three pages down on the program printout (remember, only paper output in those days), an ALTER statement, based on some variable, modifies the initial GO TO destination to something like Go To ALT-CAL-PAY-STATUS. Wow. Now think of a COBOL program of 1,000 statements containing 50 of these ALTER-GOTO constructs and the difficulty in following the logic. You needed at least 25 fingers to keep up. Maintenance of these programs was a nightmare—usually passed along to the next poor soul.
During the time of serial tape files, prior to random-access databases, we used techniques like assigning a single data field multiple data types depending on a variable such as the record type. Field 4 might be used for “color” if the record type was “commercial” and for “size” if it was “retail.” Date fields were often two digits, which precipitated the Y2K problem 30 years later. Why? Why would programmers create these maintenance nightmares?
Today, cell phones have 128 MB of memory and access to inexpensive terabytes of cloud data. The first Intel chip, introduced in 1971, had a clock speed of a little less than 1 megahertz.17 Today, chip clock speeds can exceed 5 gigahertz.18 In the Wild West era, computer speeds were glacial and memory was exorbitantly expensive. As programmers during this period, we needed to save every byte and hertz we could. We had to know which COBOL statements were fast and which were slow. This contributed to the overuse of ALTER statements, because they were fast.
During this period, development tools included flowcharts and hierarchical input–output (HIPO) diagrams. In the mid- to late 1970s, data flow diagrams and other structured methods emerged.19
In 1978 I read Tom DeMarco’s (1978) book, Structured Analysis and System Specification, and attended a Yourdon class on structured analysis taught by Steve McMenamin.20 I was an instant convert to this systematic approach to uncovering and documenting requirements. This “engineering” approach fueled my enthusiasm. When I accepted the job as software development manager at Oglethorpe, I knew incorporating these methods was part of my mission.