"Forty Years In The DP Trenches"
Reminiscences about my professional life

{ The following article was originally written for a speech delivered in November 1988 } {DP stands fo Data Processing} FORTY YEARS IN THE DP TRENCHES By Stephen Wright Autumn 1988 I have been addicted to programming for some 40 years now, and I am more likely to kick the bucket than to kick the habit. I will tell you how I got hooked; recount some of the marvelous adventures, all of them no doubt true, that befell me on the way; and tell you, finally, why my condition is incurable. Why did I become a programmer? Actually, I wanted to be a theoretical physicist. But I was too hungry. And so it goes. 1948-1949 In the Fall of 1948 I was an impecunious graduate student on the G.I. Bill at Harvard University. I had previously learned an honest trade, with a Master's degree in Electrical Engineering at the University of Iowa. I was getting interested in theoretical physics under the guidance of Julian Schwinger, who later "schwung" himself a Nobel prize in physics. My faculty advisor recommended that I take some courses in the newly formed Computer Department, under the direction of Howard Aiken. Aiken was a no-nonsense retired Lt. Commander who ran his classes with naval discipline. He taught us about computers from the ground up; symbolic logic, circuit design, engineering, and something called programming. In mid-term, we received our first hands-on programming experience We formed two-man teams to program and run a problem on the Mark I computer. It was the Sieve of Eratosthenes, an ancient Greek algorithm to compute the first n primes. Harvard Mark I -- The Mark I was an electro-mechanical computer donated to Harvard by IBM. It was about the size of a one-bedroom condo, and contained a memory consisting of 100 registers of 24 decimal digits each. Each register consisted of 24 disks attached by magnetic clutches to a cyclically rotating shaft; by de-clutching a disk for a portion of a cycle you could change its value. The readout was by electrical contacts on the disk periphery. Constants needed by a program could be entered by turning a disk manually. Input-output was done with an electric typewriter. Programming was done by means of a plugboard in the floor of the laboratory, about the size of a small bowling alley. The plugboard was wired with huge 0.5 inch diameter cables, scavenged from the Electrical Engineering labs. The plugboard was not removable! This meant that the machine was down while the laborious wiring was completed. To re-run a problem, it was necessary to start from scratch, allowing plenty of chances for wiring mistakes. In addition to the plugboard, there were two paper-tape readers from which subroutines could be read. The tape was 4 inches wide, punched with program codes, then cut and pasted into a loop several feet long and mounted in the reader. The plugboard program would activate a subroutine by starting a reader, and the loop would continue to turn until a return command was reached. Iterative subroutines, such a square root, sine, and cosine, were handled in this manner. If a program required more than two subroutines, it stopped and waited while someone manually changed the loop. Obviously, this system was inadequate for, say, air traffic control. But it could prepare tables of Bessel functions a thousand times faster and more reliably than human calculators. Class Problem -- My teammate and I completed wiring our class problem in about an hour, half of our allotted time. Imagine our surprise when we started out program and learned that 0, 9, and 27 were prime numbers! Before informing the world of our discovery, we decided to check the program and wiring and found our first bug. Its descendants were promptly spawned by our attempts to fix it. We used up our allotted time without a correct result. But good news -- I looked at the program last week and I just know that I found the last bug. Interview -- In the spring of 1950, Dr. Herbert Mitchell of Eckert-Mauchly Computer Company came to Cambridge to recruit programmers for the UNIVAC project. We discussed his plans and he asked me for my qualifications. I explained that I was Hungarian; I played a good game of chess and a better game of bridge; I had an extensive education in Latin and knew several of the raunchier poems of Catullus by heart. He was so impressed that he offered me a job as a Junior Programmer at a salary of $3600 per year. As I was barely getting by on the G.I. Bill and a very modest teaching fellowship, I accepted his offer and said good-bye to theoretical physics forever. ECKERT-MAUCHLY During the latter stages of W.W.II, Presper Eckert and John Mauchly of the University of Pennsylvania designed and built ENIAC, the first successfully operating electronic computer. After the war, they formed their own company and built an unsuccessful scientific computer called BINAC. Their dream machine was what later became UNIVAC, the first commercial computer. Their engineering genius was matched by their ineptitude as businessmen. They were rescued from bankruptcy, around 1949, by American Totalizator Company, a manufacturer of pari-mutuel machines for racecourses. Later, chronic financial problems had resulted in a takeover by Remington Rand. When I joined them in June 1950, they were still in a shaky financial condition, but had contracts for several UNIVAC's; the first one, destined for the Census Bureau, was nearing completion. The company was housed in a decrepit factory building in the Hunting Park section of Philadelphia. There were no offices, except for purchasing and accounting; everybody, including engineers, programmers, operators, and technicians, shared the factory floor with computers and accessories in various stages of completion. Imagine it! Engineers and programmers could actually talk to each other. Design changes were often made, especially in the early stages, based on such cooperation. Fortunately, by the end of the decade, engineers and programmers were properly compartmentalized. By a strange coincidence, computer machine code became virtually frozen, and is far less rich today than it was in the 1950's. And so it goes. Learning UNIVAC -- The programming staff that trained our class of 10 or so junior programmers and operators were veterans of ENIAC and BINAC: Dr. Mitchell, Betty Snider, Hildegarde Niedecker, Grace Hopper, and Margery League. This field, at least, was not only open to women from its earliest days, but one in which they clearly excelled. Still, nobody actually knew how to teach programming. The way we went about it was to learn everything about the machine, starting with blueprints and logic diagrams, tracing every signal to every circuit. It stood us in good stead later, when we were operating a defective computer in the middle of the night and stealing components from half-completed machines on the factory floor. Description of UNIVAC -- UNIVAC was a box about 12 X 12 feet. On the periphery, behind metal doors, were circuit boards (we called them "chassis") about 36 X 6 inches. Inside the box, there were 3 cylindrical tanks containing mercury delay lines; this was the memory. The circuitry, including some 5,200 vacuum tubes, was air-cooled, and we soon found out that beer stayed coldest in the corners. The operator's console included lights that could display a memory word in binary, and switches that let the operator replace it. This was the primary way debugging was done, although rudimentary dumps were available later. There was a typewriter for small amounts of input/output. The only online peripherals were Uniservos, tape units that accepted reels wound with metal tape. The reels were so heavy that the operators were required to wear safety shoes. Offline peripherals were tape-driven. There was a 120 lpm (lines-per-minute) high-speed printer, tape-to-card and card-to-tape, tape-to-paper-tape and vice versa, and Unityper (keyboard-to-tape). Memory consisted of 1000 words of 12 bytes each. They could contain data, or two instructions of 6 bytes each. There were no index registers; instructions had to be modified in memory. Each byte was 6 bits plus parity. Numbers were represented in decimal, one digit per byte. In addition to parity checking, errors were detected through parallel checking . All the logic circuitry was completely duplicated Multi-tasking was far into the future, of course. We ran one job at a time, got the output on a tape reel, then waited for a slot on the printer. Turnaround of 12 hours was pretty good. We could and did improve it drastically by working after midnight. The company at this time could not afford its own UNIVAC. We used the models that were almost ready to be shipped to the next customer. 1950-1952 In the years 1950-1952, I worked on a wide variety of problems, from scientific computations such as developing a matrix arithmetic library to some of the early commercial applications. My strongest interest was in Utility Routines, an early effort to develop tools for programmer productivity. We delivered UNIVAC's to the Census Bureau, Atomic Energy Commission, and the U.S. Air Force. Remington Rand was the second largest office equipment manufacturer, with a 5 percent market share to IBM's 90 percent. Its acquisition of UNIVAC was an enormous opportunity to jump ahead in a new field. It took them only about 3 years to muff it. The biggest problem was a sales force that was oriented to punch cards and whose biggest ambition was to go from 5 percent share to 10 percent share. They even hired General Douglas MacArthur as Board Chairman and General Leslie Groves. formerly head of the Manhattan Project, as Vice President; they proved that their talents did not extend to the business world. THE 1952 ELECTIONS In early September 1952, we received inquiries from the CBS network concerning projections for the presidential election. In mid-September a project was formed. CBS hired Dr. Max Woodbury, a statistics professor from NYU, to define a statistical model, I led a small group of programmers implementing it. Charles Collingwood, a CBS "anchor", worked with us on the broadcasting aspects. Our first design decision, which was quite sound, was to postpone the election to mid-1993. As this proved impracticable, we embarked on the most brutal crash programming effort I ever participated in. We had 6 weeks for a project no one had ever attempted before. Statistical data on past elections was scattered, disorganized, or unavailable. With the help of CBS, we had to find it, organize it, and put it into computer-readable form. We then wrote programs to analyze the data and extract statistical variables. This was only the beginning. We had to devise a system to acquire wire service and sampling data on election night, to type it in duplicate, and to create the programs to verify the typing and handle the errors. Remember: this was batch processing. Data would be collected and typed for a half-hour cycle, then fed into the computer. Only then could we concentrate on programs that would accumulate the data, analyze its variance from past elections, and compute probabilities for individual states. Other programs would then combine these into an Electoral College probability. During the last two weeks before the election, cots were set up in the factory. We did not go home until after the election. The last program was finished the day before the election. Quality assurance consisted of a single test using previous election results. We elected Roosevelt over Wilkie, so we felt pretty good. On election night, as scattered votes started coming in and some data was available by 8:30 p.m., we ran our first projection cycle. On such meager data, in an election predicted to be close, we expected a projection of 6 to 5 for one candidate or the other. It was 00 to 1 for Eisenhower. We allowed only two digits for the odds, but we could see on the console that it was 100 to 1. Of course, the projection was not released. As you recall, these events took place during the administration of President Dewey, and everyone remembered the pollsters with egg on their faces four years previously. As any reasonable person would, we panicked. After our long ordeal, our confidence level was rather low. Did we miss a decimal point someplace? Did we leave out a multiplier? Frantic checking found no problems. At 9 p.m., we ran another cycle with much more data. Same results: 100 to 1 was the maximum odds we could produce. After frantic consultations at CBS, the projection was broadcast. It caused a sensation that still has reverberations today. IBM's UNIVAC was on everyone's lips. In succeeding years, I worked on Presidential and Congressional elections through 1964, but none approached the excitement of that first one. I am proud of my part in this process, but have grave doubts about the process itself. Why report the news before it happens? Election projections were an early step in the pernicious tendency to elevate the acquisition and dissemination of news over the news itself. No more preaching, I promise. 1953-1959 In the next few years, I spent a great deal of time in shepherding various UNIVAC customers through their first applications. Data processing was in its infancy, and the manufacturer was expected not only to train the programmers, but to help design and implement their applications. I spent months at a time with users such as U.S. Steel in Pittsburgh and Gary, Con Edison in New York, and General Electric in Louisville. My six months in Gary were particularly interesting, if that is the right word. The UNIVAC was installed in mid-summer in a non-air-conditioned office in a steel mill. The cooling system was custom designed; instead of the normal air cooling, it was water-cooled. To save water costs, a line was run directly into the adjacent Lake Michigan. The cooling system overheated when small fish got into the pipeline. A resourceful maintenance engineer installed a filter at the intake. This worked fine until the filter clogged up with fish. His final solution was to put a trap ahead of the filter, and a grinder with a hand crank. Each morning he would go down to the lake and grind up the fish. We had the world's first computer cooled with bouillabaisse! In 1956, the ERA division of Remington Rand in Minneapolis was given the job of upgrading to UNIVAC II. This included converting to magnetic core memory, twice the size of UNIVAC I's, adding 3 index registers, and various improvements to the instruction set. I commuted to Minneapolis and worked with the engineers, headed by William Norris. A year or two later, he left UNIVAC with some of those engineers and founded Control Data. During the late 1950's, I was the chief programming troubleshooter for RemRand. This was a very convenient title -- at this time I was heavily involved with playing tournament bridge, and I could usually arrange for trouble someplace near a Regional Tournament. It was a lot of fun. FOUNDING OF ADR In the summer of 1959, I received a phone call from Elwood Kauffman, a fellow programmer from my early days at Eckert-Mauchly, who was doing contract programming on his own. How would I like to give up my well-paying job with RemRand and set up an independent company ? It sounded good to me (I was still single then) and five of us met and decided to form the first independent software company. Besides Woody and myself, there were five others, all UNIVAC veterans. Our first decision was: where? There were two votes for New York, two for Philadelphia and one for Princeton, NJ, where Woody lived. He won because he knew of a plumbing supply house that was going out of business and would provide us with cheap offices. Next, we elected a president. Woody won unanimously because he owned a book on how to run a business. Choosing a name came next. We became Applied Data Research (ADR). I was the purchasing agent and bought 12 desks, chairs, filing cabinets, partitions and an electric typewriter for $1500 at a bankruptcy sale. In September. we were in business. In the next two months, Marty Goetz and Bob Wickenden joined us, completing the initial staff. 1959-1968 Our first job was a subcontract from General Precision Laboratories, who landed a contract from the FAA to provide the hardware and software for an Air Traffic Control system. It was an ideal beginning. We supplied programmers, we had no risk, we worked on a cushy job that had a snowball's chance in hell of ever being completed. If you don't know the definition of "chutzpah", Air Traffic Control on a 64 Kb, 1960 computer classifies. Before a sudden sense of realism terminated this project, we got into the COBOL business. In 1960, RCA was in a race with UNIVAC to deliver the first COBOL compiler. We helped them design and implement the compiler for thc RCA 501, beginning a long and fruitful relationship with RCA. Incidentally, the race ended in a tie. Another project at RCA was a flowcharting system called Autoflow. From a flowchaning system, Autoflow grew into a programmers' toolbox and this was actually our first product, sold to users rather than manufacturers. It was also the backbone of our business for many years. We were considered compiler expens. I worked with RCA to provide a COBOL compiler and a report generator for the RCA301. We also pulled a real coup with UNIVAC. They had contracted with Computer Sciences, our primary competitor, for a COBOL compiler for UNIVAC-III. They ran into trouble with it, and we got the contract to improve and maintain it. Despite our technical successes, we ran into financial trouble and by mid-1963 we were on the verge of bankruptcy. We negotiated with Auerbach Associates, a computer technical publisher, for a rescue. The deal fell through; we wanted $60,000 for the company and Auerbach offered $20,000. Fortunately, the bank had faith in us and we came through to survive for another 25 years. Just for comparison, 5 years later our stock was worth $25 million. Ten years later, in the 1973-1974 crash, it was worth $1 million. These were the go-go years. ON MY OWN In 1964,1 got restless and decided to strike out on my own. I left ADR and became an independent consultant. I had the foresight to sell most of my ADR stock. This saved me from later wallowing in a life of luxury and idleness. I worked on the RCA3301 and SPECTRA-70 compilers,among others. I did a great deal of traveling on various consulting jobs for users and manufacturers But I found that interesting one-man jobs were not that easy to find. METACOBOL I returned to ADR in December 1968. Marty Goetz wanted me to work on a generalized COBOL program generator. I have a phobia for anything generalized, and I converted the project into a macro facility for COBOL. This was MetaCOBOL, which became a powerful tool for language manipulation. I installed the first MetaCOBOL at Memorial Baptist Hospital in Houston in September 1968. There were no complaints. There were no bugs. In fact we haven't heard from them to this day and have no idea whether they used it. We did get their check. Since then, MetaCOBOL has grown through some 15 releases into a much more powerful language. For a 20-year old product It is still quite vigorous. Another product we developed was CPA, the Cross-program Analyzer This derived usage profiles of data-names and program constructs across a series of programs in an application. It was a useful tool for COBOL migration to Database or to new versions of the language. After a few sales it petered out. We learned that if you can't sell to your own salesmen, you won't sell to many customers. STRUCTURED PROGRAMMING In the early 1970's, we heard rumors ahout a new technique called "sculptured programming". We assumed it concerned programmers whose code was so error-free that they carve it into stone, rather than using paper and pencil like the rest of us. We found out that we were wrong and that Structured Programming really was something worthwhile to look into. I was immediately attracte to the technique because I hate to write comments, and it was said that well-structured code is its own documentation. We developed macros that let a MetaCOBOL user write structured COBOL code. We also figured that what was good for the user was good for us, so we introduced structured directives into the macro language. Eventually, Bob Oakley developed an in-house language called HAL that allows us to use structured Assembler language for our developments. CA-IDEAL (a 4GL application development system), for example, is written in HAL. CODASYL Our interest in structured programming led to ADR representation on Codasyl for a number of years. One anecdote will serve to illuminate how committees such as this operate. While Codasyl develops the COBOL language, ANSI is the committee that actually shapes it into a standard. The ANSI committee received a letter criticizing the 1974 standard, alleging that a particular paragraph was ambiguous. The letter was put on the agenda, and in due course came up for discussion. The committee carefully reviewed the offending paragraph in the light of the criticism and finally decided that it was not ambiguous. By a vote of 6 to 5. It is important to remember that Codasyl members were not there as individual experts, but as representatives of all the major manufacturers, as well as users and software houses. Decisions made had an economic impact. For example, the maximum size of 18 digits for a numeric field was chosen for the standard precisely because no one had a compiler that could handle it, or a machine that could efficiently process it. It was a level playing field. I learned a lot about politics in those days and gained some respect for the horse-trading that goes on in Congress. BEHIND THE IRON CURTAlN Between 1977 and 1979, I made two trips to Russia and one to Bulgaria, participating in seminars on ADR products sponsored hy our Finnish representative, Risto Kivivuori. I learned a great deal on these trips, not the least about my capacity for alcohol. We set up a demonstration of Roscoe (an online programming system) in Leningrad. The demonstration was on a Finnish terminal, connected through a Hungarian modem on an international line to a computer in Helsinki. The computer was a Soviet ES-20, an IBM clone. Improbably, the connection was made the first time and Roscoe actually came up. Our Finnish tech rep started to demonstrate Roscoe to a group of Soviet programmers. After 5 minutes, she asked if there were questions so far. "Yes", said a voice in perfect English from the back, "when are you going to let us play with it?" I knew then that there is an international brotherhood of programmers . Incidentally, one of the soviet programmers at that seminar now works across the hall from me. CA-IDEAL Since 1981, I have spent most of my time on CA-IDEAL. I have worked on the compiler, mostly on the CA-IDEAL executor. Currently, I am working on the Debugger, as well as designing and implementing improvements in the Report Writer. LOOKlNG BACK How does today compare with 40 years ago? Some things haven't changed much. Forests are still being denuded -- we generate more paper than ever. Computer speed and memory -- about the same -- about half of what we need to do a really good job. The cost of large machines is still in the megabuck range. What has changed is that computers have crept into nearly every aspect of our lives, even under the hoods of our cars. Peter's Principle is operating on a gigantic scale: more, cheaper power spawned applications undreamed of in the past. If a real computer virus started eating microchips, our economy would collapse. On a more personal level, I was much smarter 40 years ago. I knew, or thought I knew, nearly everything there was to know about computers: it wasn't that much. Today, you must choose whether you want to know a little bit about a lot of things, or seek out a small niche of the computer world. Today, I can't compete with 9-year olds who know much more about the Macintosh than I ever will. So much for mature wisdom. CONCLUSION Monday morning in Princeton, a young lady from tech support will drop a 25-pound partition dump from Singapore on my desk. She will interpret the pijin-English description of the problem and apologize for sticking me with another boring job. A boring job? The great detective springs into action, investigating a bloodless crime, one he may very well have committed. He is Inspector Javert, implacably tracking down the suspect without a trace of mercy. He is Superintendent Gideon of Scotland Yard, coolly organizing vast resources to trap the perpetrator. He is Hercule Poirot, using the little grey cells in a delicate game of cat and mouse. He is Sherlock Holmes, sucking on his pipe as he weaves implausible threads of deduction from the slenderest of clues. In what other line of work can you indulge such fantasies? Play with such bizarre toys? Savor the satisfaction of such accomplishments? That's why I am still a programmer.