Broad Band

by Claire L. Evans

  Grace’s paper ignited the computing community, but there was work to be done. Her first compiler, A-0, was elementary. “It was very stupid,” she explained. “What I did was watch myself put together a program and make the computer do what I did.” Although it smashed conventional programming techniques in speed 18:1, the machine code it created—the elemental, binary instruction set the computer actually executed—remained inefficient. These days, the elegance of code is mostly aesthetic, but in the early 1950s, it was still cheaper to pay programmers to manually check programs for errors than it was to burn an extra hour of computer time with clunky machine code. Within a year, Grace and her programming staff had written a slightly less cumbersome A-1 compiler; in the spring of 1953 came the A-2. With each iteration, compilers grew more sophisticated, more user-friendly; A-2 introduced what Grace called “pseudo-code,” a kind of in-between language more human than computer. It wouldn’t seem particularly friendly to a modern programmer, but this shorthand was the first step toward programming languages nonexperts could use. That would be Grace Hopper’s legacy.

  Getting the ball rolling on automatic programming was a big accomplishment, but it created an entirely new set of problems. Designing compilers and pseudo-code was beginning to feel like inventing new languages, more art than science. The new syntax had to hold the compiler together while remaining coherent to users—a language is only ever as useful as the fluency of its speaker, after all. Grace saw the proliferation of new compilers and pseudocode as a potential Tower of Babel situation, with competing, mutually incomprehensible languages crowding each other out. She proposed a few solutions. Her influential business compiler, MATH-MATIC, employed the globally understood language of mathematics as its lingua franca. Its descendant, FLOW-MATIC, assigned mathematical variables to commonly used words and phrases. These natural language commands served double duty as documentation, and their relative comprehensibility made it possible for nontechnical project managers to assess work being done. But the larger question remained: Could a single language be understood by every computer on Earth?

  The earliest meeting to discuss this question was initiated by Mary Hawes—one of Grace Hopper’s former colleagues, with whom she’d codeveloped FLOW-MATIC at Remington Rand—when she “buttonholed” a well-known computer scientist, Dr. Saul Gorn, at a conference in San Francisco, “asking if he didn’t think it was time for a common business language.” In April 1959, Grace called a follow-up meeting at the University of Pennsylvania, where she was adjunct faculty. Everyone in attendance agreed with Mary: the time was nigh for a shared, business-facing, hardware-independent programming language. Remington Rand wasn’t the only company up to its ears in costly data installations; Grace’s informal committee was full of competitors, like IBM and the Radio Corporation of America (RCA), suffering the same growing pains. But the undertaking needed a neutral—and influential—sponsor. Grace flexed some navy connections and approached the Department of Defense, which at that time was running 225 computer installations with plans for many more.

  Only a month after the meeting at Penn, the DoD hosted the first organizational meeting of the Conference on Data Systems and Language, or CODASYL, at the Pentagon. Every major computer manufacturer sent diplomats to rub elbows with government brass and representatives from private industry. The common cause was a forward-thinking, easy-to-use language, preferably in simple English, that would be independent of any specific machine. Three committees were formed: short-range, intermediate-range, and long-range. The first would examine existing compilers, like Grace Hopper’s FLOW-MATIC, FORTRAN, and the AIMACO language developed by the air force, to decide what worked and what didn’t. After that analysis, they’d write up specifications for an interim language. The intermediate group would study language syntax and business language trends, then build on the first group’s effort. Finally, the long-range group would gather all the first and second groups’ research and use it to create a universal business language. A rigorously tiered process with deliverables at every step along the way: honestly, it could only have been dreamed up by computer programmers.

  The committees promptly went haywire. There was no such thing as an interim language; it was far too time-consuming and expensive to switch languages at all. Grace estimated that it would cost $945,000 and 45.5 man-years—the notion of kilogirl hours being long gone from the lexicon at this point—to implement a new compiler at Remington Rand. Whatever stopgap language the short-range committee created would have to be there to stay.

  “In no way was this language going to be an interim solution,” concluded Grace’s old Eckert-Mauchly colleague Betty Holberton, a member of the short-range committee who was, by then, supervising advanced programming at the navy’s Applied Math Lab. “This language was going to be ‘it’ as far as I was concerned.” This left the short-term group, which included three women (beyond Holberton and Mary Hawes, there was Jean E. Sammet from Sylvania Electric Products, also a Hopper protégé), to write the new business language in fewer than three months. Because programmers love acronyms, the group became known as the PDQ Committee—they’d have to move mountains of code pretty damn quick. PDQ made good on their name, delivering their findings for the new common business oriented language, COBOL, in December 1959. That following January, the specs were printed. The long-range committee was never even formed.

  COBOL changed the world. The Department of Defense ran all its computer installations with COBOL and insisted that suppliers provide hardware that supported it, dictating the direction of the computing industry for a decade. Ten years after its implementation, COBOL was the most widely used programming language in the industry, and by the turn of the millennium, 80 percent of all code on the planet was written in COBOL, representing some seventy billion lines of code. This ultimately proved to be a huge problem: bound by the memory constraints of 1950s-era computers, CODASYL had decided on a two-digit convention to display the year, so the switch from “99” to “00” in the year 2000, it was feared, would plunge the world into chaos, in a much-ballyhooed “Y2K bug.” Groups of COBOL programmers actually had to come out of retirement to squash this final and hairiest moth in the machine. It goes to show the effectiveness of Grace Hopper’s efforts. The software industry, desperately needing a standard, leaped on COBOL. But even though it was a language built to save the future of programming, its designers didn’t anticipate just how long it would last.

  COBOL was written to suit the interests of a diverse group of people; it sacrificed elegance for readability and efficiency for machine independence. It also developed a reputation for being thorny, verbose, and convoluted. Most programmers explicitly despise it. Several textbooks omit it completely. The academic computer science community, which hadn’t been consulted on its design, refused to engage with it. The Dutch computer scientist Edsger W. Dijkstra famously wrote that COBOL “cripples the mind,” adding that “its teaching should, therefore, be regarded as a criminal offence.” Jargon File, a hacker dictionary that collected computer slang from the mid-1970s onward through various shared computer networks before first being published as The Hacker’s Dictionary in 1983, includes what is easily the most withering definition of COBOL:

  COBOL: //Koh’Bol/, N.

  [Common Business-Oriented Language] (Synonymous with evil.) A weak, verbose, and flabby language used by code grinders to do boring mindless things on dinosaur mainframes. Hackers believe that all COBOL programmers are suits or code grinders, and no self-respecting hacker will ever admit to having learned the language. Its very name is seldom uttered without ritual expressions of disgust or horror.

  COBOL’s creators wrote this off as a “snob reaction.” Jean Sammet, one of the chairs of the CODASYL committee and a great admirer of Grace Hopper, pointed out that “usefulness and elegance are not necessarily the same thing.” She remembered the monumental nature of the task: COBOL represents an attempt by a group of competitors to set aside their interest
s and create something benefiting everyone at the table, many of whom sacrificed existing projects for business or commercial software languages. COBOL was designed by committee, but it was technological armistice, a ceasefire for the good of the art.

  In Jean Sammet’s estimation, Grace Hopper did “as much as any other single person to sell many of these concepts from an administrative and management, as well as technical, point of view.” For this, Grace is remembered as the grandmother of COBOL. Like a grandmother, she was responsible for the child but did not deliver it. Her diplomatic skills brought competitors, programmers, professional organizations, the military, and clients together. Her insistence that this milestone be reached collaboratively, rather than through competition for market share, was thirty years ahead of its time: the next generation of programmers to come of age might have sneered at COBOL’s unwieldy syntax, but many would employ a similar model of distributed innovation. As her biographer points out, Grace’s emphasis on collaborative development, and the network of volunteer programmers she mobilized, predated the open-source software movement by four decades. Further, building common languages that remained consistent even as hardware came and went would prove essential to the evolution of computing. If programmers had been forced to start from scratch every time a new computer came out, they’d have been playing catch-up for eternity. But automatic programming—and the foundation of efficiency, accessibility, and machine independence on which it was laid—cemented the possibility for programming to develop as a functional art form.

  Beyond Grace, many women were involved in the development of automatic programming—a disproportionate amount, in fact, even relative to the demographics of their industry. Like Betty Holberton with her Sort-Merge, they developed compilers and generators. At Remington Rand, Adele Mildred Koss, a former UNIVAC programmer from the Eckert-Mauchly days, created an Editing Generator, which read the specifications of a file and automatically produced a program to transform it into different formats; the idea was refined by Nora Moser, a programmer at the Army Map Service, one of the first people to implement Grace’s A-2 compiler. Moser would also help out on the PDQ committee, along with three other women, Deborah Davidson from Sylvania, Sue Knapp from Honeywell, and Gertrude Tierney from IBM. The final six-person committee to develop COBOL’s specifications included two women, Gertrude Tierney and Jean Sammet, one of the first people, let alone women, to teach computer programming at a graduate level in the United States.

  Admittedly, the bureaucratic labor of programming standards committees and the highly technical work of compiler design are difficult to dramatize, but for many of these women, the advancement of automatic programming represented an opportunity to assert their own importance, particularly in relation to hardware engineers. A compiler, Nora Moser noted, was like a “pseudocomputer,” a machine made from code alone, and Grace Hopper observed that it constituted a “second-level” of operation beyond the workings of the machine itself, reproducible and lightweight enough to be sent in the mail. This put programmers on the same level as engineers—forging connections with symbols instead of soldering wire.

  Like Grace, these women were overworked. Their employers often expected them to provide support to customers in addition to writing, testing, and debugging computer code. In an exploding industry, this was nearly impossible and, in many cases, counterproductive. But with “both the expertise to devise solutions and the incentive to make programming easier for experts and novices alike,” they were in a unique position to effect real change, and did. Grace Hopper wasn’t the first woman to believe in programming, automatic or otherwise. Many of Grace’s female peers worked tirelessly to develop and standardize programming strategies that would transform the early computer industry, just as Ada Lovelace had made the mental leap from hardware to software a century before. But although the Difference Engine was never finished and the Analytical Engine was only imaginary, she knew, just as Grace did: a computer that does only one thing isn’t really a computer.

  It’s just a machine.

  Chapter Five

  THE COMPUTER GIRLS

  In 1967, the April issue of Cosmopolitan ran an article, “The Computer Girls,” about programming. “The Computer Girls,” the magazine reported, were doing “a whole new kind of work for women” in the age of “big, dazzling computers,” teaching the “miracle machines what to do and how to do it.” Just as a woman twenty years previous might have chosen a career in education, nursing, or secretarial work, today, its author implied, she might consider computer programming. In the photographs accompanying the article, an IBM Systems Engineer named Ann Richardson is pictured handling punch cards, flipping switches, and “feeding facts” into the computer. Looking chic in a striped, sleeveless blouse and a neat beehive, she’s surrounded by faceless men in identical suits, who look down at her as she smiles brightly, a miniskirt among the mainframes.

  Grace Hopper, by then in her early sixties, was back in active navy service, heading a programming languages group in the navy’s Office of Information Systems Planning. Quoted in the Cosmopolitan article, she used one of her favorite analogies about women and programming, comparing writing programs to planning a dinner party: “You have to plan ahead and schedule everything so it’s ready when you need it.” It may seem like a reductive statement from someone who would eventually develop a fleet-wide tactical system for nuclear submarines, but that was Grace’s style. Practical applications were the most important thing, and she always connected computers to living, breathing, everyday life. But the last word in the Cosmopolitan article comes from a male programmer. “‘Of course we like having the girls around,’ he declares, ‘they’re prettier than the rest of us.’”

  Something happened to the generation of programmers after Grace Hopper and her peers. Although the Cosmo article suggests that women were being encouraged to pursue programming as an alternative to secretarial work, the field was quickly becoming far less welcoming to women than it had been even a decade before. Some estimates peg female programmers as between 30 and 50 percent of the workforce throughout the 1960s, but instead of running departments and advancing the art, they were starting to cluster “at the lower end of the occupational pool,” in lower-status jobs like keypunch operator, the 1960s equivalent of data entry, punching little holes in paper cards all day long.

  At the same time, technology pundits wrote often and lustily about a “software crisis” plaguing the computing industry. Due to a massive shortage in skilled programmers, software projects were coming in late, under specifications, and riddled with bugs. Many of these were dramatic, public failures: in the early 1960s, IBM delivered the OS/360 operating system a year late and four times over budget, and NASA was forced to destroy the Mariner I spacecraft, intended to probe the mysteries of Venus, because of a simple programming error.

  Writing programs may be like planning a dinner party, but it also demands perfection on a level unlike any previous human undertaking; a single misplaced comma can send a rocket tumbling back to Earth. “If one character, one pause, of the incantation is not strictly in proper form, the magic doesn’t work,” wrote Frederick Brooks, who managed the disastrous OS/360 operating system at IBM. This can make programming difficult to learn. In the early decades of the field, it’s also what made it resistant to the industrial production that would drive the growth of the computer hardware business: writing software is like writing poetry with the unforgiving precision of equations, and it has a practical capacity to impact human lives on an unprecedented scale.

  Some historians have attributed the “software crisis” to the disproportionate development of hardware and software: as faster, brawnier computers came into use, programmers were helpless to catch up. Others have cited a personality clash between programmers—if not women, then uniquely creative, difficult, and occasionally arrogant men—and their straitlaced industrial and governmental managers. But there’s a third view, one that reflects how the s
oftware crisis coincided with the long, slow decline of women in senior programming positions throughout the industry.

  By the late 1960s, even as Cosmo was pushing programming as a neat alternative to answering office phones, women in computing were being paid significantly less than their male counterparts. In a tradition dating all the way back to those nineteenth-century human computing offices that hired women to save money, female programmers were paid about $7,763 a year compared with a median $11,193 yearly salary for men doing the same job. This wage discrimination, combined with a structural unwillingness on the behalf of computer companies to make space for childcare obligations, drove women from the industry. Meanwhile, the software crisis grew so severe that NATO called an international conference in 1968 to address the problem. No women were invited.

  It was held in the Bavarian ski resort town of Garmisch. Between runs down the Zugspitze, the men attending banged out a new approach to programming, one they hoped would rein in some of the problems plaguing the computing industry. The most significant change they made, arguably, was semantic: programming, they decided, would heretofore be known as software engineering. As such, it would be treated like a branch of engineering rather than a rogue, wild-blooming field roamed by fiercely independent, self-directed misfits and women. Engineering is a job with clear credentials, not a shadowy priesthood. This change signaled a larger renegotiation of computing’s professional status that would unfold through professional journals and societies, hiring practices, and certification programs throughout the 1960s and 1970s. The more the discipline professionalized, the more it grew implicitly masculine. The introduction of formal educational prerequisites for programming jobs, for example, made it harder for self-taught programmers to find employment—a change that penalized female candidates, particularly those who might have taken time off from school to raise children, above all. If computer programming “began as women’s work,” writes historian Nathan Ensmenger, “it had to be made masculine.”