Ziller and Nelson had one of most difficult assignments: analyzing and optimizing the so-called inner loops of the compiler. Fine-tuning the inner loops – essential repeated operations – would be key to making the compiler efficient. Ziller and Nelson would have to automate, in software, the work that human programmers regarded as the height of their craft: squeezing instructions out of those loops.
Theirs was the procedural artistry of programming. They studied the inner loops to find the most efficient method of execution – that is, using the least machine time. They then had to devise the programming statement that would invoke that efficient step – the particular – when the compiler was presented with similar problems – the general case. “It was a repetitive process we developed, a constant iteration of improvements,” Ziller explained. “We were constantly trying to save one ‘load’ or ‘store’ instruction, and juggling the order of execution so that step by step we removed more and more calculations.”
Because machine time was a scarce resource, FORTRAN was debugged mainly at night. In the FORTRAN compiler, the Backus team was working on path-breaking software technology. But they used the traditional programming medium of paper tablets and punched cards, which would die only later, starting in the 1960s – thanks to hardware improvements in memory and storage technology – permitting a programmer to code on a keyboard terminal connected to the computer, and still later, directly on a personal computer. The FORTRAN programmers first wrote their code out on sheets of lined or grid-patterned paper. The programs were then keypunched onto punched cards, and the FORTRAN team did their own keypunching. Next, the cards were placed into a card-reading machine, which deciphered the digital perforations on each card. The card reader then fed the data and programming instructions into the computer, and the program ran. (FORTRAN was actually distributed to customers in late 1957 on magnetic tapes, according to David Sayre, since duplicating the big deck of cards accurately proved very difficult.) For nearly a year, the team rented rooms at the Langdon Hotel, which passed from the New York scene long ago, sleeping a little during the day and staying up all night to get time on the 704 computer in the headquarters annex nearby. At dawn each day, they retreated and placed the most resistant bugs into a folder for special attention and further work. The file was jokingly labeled “Necropolis” – a place of horror and death.
The Fortran project was managed with a light corporate touch. Still, the group did have to conform to certain IBM rules. In administering these Backus, it seems, was all but subversive. At the time, IBM conducted yearly employee reviews called the “Performance Improvement Program,” or PIP, for short. The PIP, like most such programs today, followed a rigid formula, with numbers and rankings. Backus decided the PIP system was ill-suited for measuring the performance of his programmers, so his approach was to mostly ignore it. One afternoon, for example, he called Lois Haibt over for a chat. He talked about her work, said she had been doing an excellent job, and then pushed a small piece of paper across the desk saying, “This is your new salary” – a pleasing raise, as Haibt recalled. As she got up to leave, Backus mentioned in passing, “In case anyone should ask, This was your PIP.”
