Recoding Gender: Women's Changing Participation in Computing 9780262018067, 2012009891, 0262018063

Table of contents :
History of Computing Series......Page 3
Contents......Page 8
Acknowledgments......Page 10
Introduction: Rediscovering Women’s History in Computing......Page 12
Chapter 1 Breaking Codes and Finding Trajectories: Women at the Dawn of the Digital Age......Page 22
Chapter 2 Seeking the Perfect Programmer: Gender and Skill in Early Data Processing......Page 50
Chapter 3 Software Crisis or Identity Crisis? Gender, Labor, and Programming Methods......Page 84
Chapter 4 Female Entrepreneurs: Reimagining Software as a Business......Page 124
Chapter 5 Gender in Academic Computing: Alternative Career Paths and Norms......Page 156
Appendix: Oral History Interviews Conducted For This Project......Page 188
Notes......Page 190
Bibliography......Page 236
Index......Page 254

Citation preview

Science, Technology, and Society at Virginia Tech and the author of Inventing the Internet (MIT Press, 1999).

history of computing/gender studies

“We’ve heard stories about women pioneers in computing, and some of us have our own to tell, but Janet Abbate captivates us as she recounts the roles of early women in defin­ ing the field. These inventive women did more than battle limiting rules and expecta­ tions of their times but created their own rules and succeeded at the new game. Abbate offers this history in the context of a thoughtful and balanced exploration of how a newly formed field was, and continues to be, impacted by evolving forces of gender bias. There are amazing stories and important lessons here for all of us.” ­—Irene Greif, IBM Fellow and Director, IBM Center for Social Business “In stories that can only be described as both heroic and cautionary, Janet Abbate shows how women worked to establish a place for themselves in the field of computa­ tion, how they succeeded, and how they were frustrated in their efforts. She provides a well-written account of how a technology that had promised a universal, logical ma­ chine became deeply intertwined with issues of gender and identity. Abbate’s women help us to understand how we arrived at our modern perceptions of computing careers.” —David Alan Grier, George Washington University; 2013 President of the IEEE Com­ puter Society

Recoding Gender Women’s Changing Participation in Computing

Abbate

“This timely book takes a deep dive into the important question of why women are such a minority in computing technology. I hope the issues raised in this valuable book will inspire more women to join this growing field.” —Lixia Zhang, Computer Science Department, University of California, Los Angeles

Recoding Gender

Janet Abbate is Associate Professor of

“How did programming go from being ‘women’s work’ to a ‘boys-only clubhouse’? Janet Abbate has woven extensive interviews with women on both sides of the Atlantic who were instrumental in the beginning of the digital computer industry into a fas­ cinating story of how the culture of a profession develops. This book should be read by every woman in computing and by men who want to understand how the current culture of programming evolved from very different roots.” —Robin Jeffries, Systers’ Keeper, Systers Forum, Anita Borg Institute for Women and Technology The MIT Press Massachusetts Institute of Technology Cambridge, Massachusetts 02142 http://mitpress.mit.edu 978-0-262-01806-7 90000

History of Computing series

9 780262 018067

Janet Abbate

Recoding Gender Women’s Changing Participation in Computing Janet Abbate

Today, women earn a relatively low percentage of computer science degrees and hold proportion­ ately few technical computing jobs. Meanwhile, the stereotype of the male “computer geek” seems to be everywhere in popular culture. Few people know that women were a significant presence in the early decades of computing in both the United States and Britain. Indeed, programming in post­ war years was considered women’s work (perhaps in contrast to the more manly task of building the computers themselves). In Recoding Gender, Janet Abbate explores the untold history of women in computer science and programming from the Sec­ ond World War to the late twentieth century. Dem­ onstrating how gender has shaped the culture of computing, she offers a valuable historical per­ spective on today’s concerns over women’s under­ representation in the field. Abbate describes the experiences of women who worked with the earliest electronic digital computers: Colossus, the wartime codebreaking computer at Bletchley Park outside London, and the American ENIAC, developed to calculate bal­ listics. She examines postwar methods for recruit­ ing programmers, and the 1960s’ redefinition of programming as the more masculine “software engineering.” She describes the social and busi­ ness innovations of two early software entrepre­ neurs, Elsie Shutt and Stephanie Shirley; and she examines the career paths of women in academic computer science. Abbate’s account of the bold and creative strategies of women who loved computing work, excelled at it, and forged successful careers will provide inspiration for those working to change gendered computing culture.

Recoding Gender

History of Computing William Aspray, editor Janet Abbate, Recoding Gender: Women’s Changing Participation in Computing John Agar, The Government Machine: A Revolutionary History of the Computer William Aspray and Paul E. Ceruzzi, The Internet and American Business William Aspray, John von Neumann and the Origins of Modern Computing Charles J. Bashe, Lyle R. Johnson, John H. Palmer, and Emerson W. Pugh, IBM’s Early Computers Martin Campbell-Kelly, From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry Paul E. Ceruzzi, A History of Modern Computing I. Bernard Cohen, Howard Aiken: Portrait of a Computer Pioneer I. Bernard Cohen and Gregory W. Welch, editors, Makin’ Numbers: Howard Aiken and the Computer John Hendry, Innovating for Failure: Government Policy and the Early British Computer Industry Michael Lindgren, Glory and Failure: The Difference Engines of Johann Müller, Charles Babbage, and Georg and Edvard Scheutz David E. Lundstrom, A Few Good Men from Univac René Moreau, The Computer Comes of Age: The People, the Hardware, and the Software Arthur L. Norberg, Computers and Commerce: A Study of Technology and Management at Eckert-Mauchly Computer Company, Engineering Research Associates, and Remington Rand, 1946–1957 Emerson W. Pugh, Building IBM: Shaping an Industry and Its Technology Emerson W. Pugh, Memories That Shaped an Industry Emerson W. Pugh, Lyle R. Johnson, and John H. Palmer, IBM’s 360 and Early 370 Systems Kent C. Redmond and Thomas M. Smith, From Whirlwind to MITRE: The R&D Story of the SAGE Air Defense Computer Alex Roland with Philip Shiman, Strategic Computing: DARPA and the Quest for Machine Intelligence, 1983–1993 Raúl Rojas and Ulf Hashagen, editors, The First Computers: History and Architectures Dorothy Stein, Ada: A Life and a Legacy John Vardalas, The Computer Revolution in Canada: Building National Technological Competence, 1945–1980 Maurice V. Wilkes, Memoirs of a Computer Pioneer

Recoding Gender Women’s Changing Participation in Computing

Janet Abbate

The MIT Press Cambridge, Massachusetts London, England

© 2012 Massachusetts Institute of Technology All rights reserved. No part of this book may be reproduced in any form by any electronic or mechanical means (including photocopying, recording, or information storage and retrieval) without permission in writing from the publisher.   MIT Press books may be purchased at special quantity discounts for business or sales promotional use. For information, please email [email protected] or write to Special Sales Department, The MIT Press, 55 Hayward Street, Cambridge, MA 02142.   This book was set in Sabon by the MIT Press. Printed and bound in the United States of America.   Library of Congress Cataloging-in-Publication Data   Abbate, Janet. Recoding gender : women’s changing participation in computing / Janet Abbate.   p.  cm. — (History of computing) Includes bibliographical references and index. ISBN 978-0-262-01806-7 (hardcover : alk. paper) 1. Women in computer science.  2. Computer industry.  I. Title. QA76.9.W65A33 2012 004.082—dc23 2012009891 10 9 8 7 6 5 4 3 2 1

For Tom and Wendy

Contents

Acknowledgments ix Introduction: Rediscovering Women’s History in Computing  1 1  Breaking Codes and Finding Trajectories: Women at the Dawn of the Digital Age  11 2  Seeking the Perfect Programmer: Gender and Skill in Early Data Processing 39 3  Software Crisis or Identity Crisis? Gender, Labor, and Programming Methods 73 4  Female Entrepreneurs: Reimagining Software as a Business  113 5  Gender in Academic Computing: Alternative Career Paths and Norms 145 Appendix: Oral History Interviews Conducted for This Project  177 Notes 179 Bibliography 225 Index 243

Acknowledgments

This research was supported by NSF grant #0080777, which allowed me to travel to conduct archival and oral history research. Fifty-two remarkable women (named in the appendix) generously shared their life stories with me. One book cannot do justice to the richness of their experiences; readers can find the full interviews online at the IEEE History Center, where Mike Geselowitz and Sheldon Hochheiser assisted me in archiving my oral history collection. Phil Stewart brought a keen sense of language (and humor) to the transcription process. I gratefully acknowledge support from a Senior Fellowship at the Smithsonian Institution and a Eugene Garfield Fellowship at the Chemical Heritage Foundation, which gave me time to write. I also wish to thank the archivists at the University of Pennsylvania, the Smithsonian National Museum of American History, the Hagley Library, the Charles Babbage Institute, and the Computer History Museum. My first role model for a woman thriving in computing was Max (Alix) Vasilatos, my indomitable boss at MIT’s Project Athena, where I worked as a programmer before starting my academic career. Denise Gürer was my co-organizer for a session at the 2004 Grace Hopper Celebration that brought in a panel of female trailblazers to tell their stories to the next generation. Caroline Simard, Deanna Kosaraju, and Jerri Barrett at the Anita Borg Institute were generous with their time and resources. Historians of computing Tom Misa, Jeff Yost, Veronika Oechtering, and David Grier helped me think through the intersections of gender and computing, and Tim Bergin gave me the opportunity to guest edit a special issue of the Annals of the History of Computing on women and gender. Amy Slaton helped me hone my arguments through countless drafts with her usual

x  Acknowledgments

wit and insight. My colleagues at Virginia Tech supported me through the long writing process, while Stacey’s and Natalia’s in Falls Church, Virginia, provided the coffee that fueled many hours of writing. My deepest gratitude goes to my husband, Tom, who unfailingly gave me strength and inspiration. My daughter, Wendy, made her joyful appearance in the midst of this project; the future belongs to her.

Introduction: Rediscovering Women’s History in Computing

It really amazed me that these men were programmers, because I thought it was women’s work! —Elsie Shutt, hired by Raytheon in 19531 I was hired as a programmer. . . . It was something that women were believed to be good at. —Fran Allen, hired by IBM in 19572 It never occurred to any of us that computer programming would eventually become something that was thought of as a men’s field. At the time—just as now, actually—in the intro, beginning, lower levels of employment, it was at least half women. There were a lot of women who made straight As in math! —Paula Hawthorn, hired by Texaco in 19663

Many people are surprised to discover that women have a long history in computing. In the United States and Great Britain, the nations covered in this book, women today hold a relatively low percentage of computer science degrees and technical computing jobs, and popular stereotypes of male computer geeks abound. Yet women were a significant presence in the early decades of computing. They made up the majority of the first programmers during World War II; they held positions of responsibility and influence in the early computer industry; and they were employed in numbers that, while a small minority of the total, compared favorably with women’s representation in many other areas of science and engineering. Some female programmers of the 1950s and 1960s would have scoffed at the notion that programming would ever be considered a masculine occupation, yet these women’s experiences and contributions were forgotten all too quickly.

2  Introduction

This book explores the untold history of women in computer science and programming from the Second World War to the late twentieth century. It demonstrates how gender has played an unacknowledged role in the history of computing, shaping beliefs and practices on issues ranging from the nature of expertise to the organization of work to the purpose of computer science. Although this is primarily a historical work, I also highlight connections between the gendered practices of the past and policy issues of today. In what has become a much-discussed paradox, women’s numbers in computing have declined since the mid-1980s in the United States and United Kingdom, even as women’s participation in other areas of science and technology has risen (figure I.1). Computer scientist Tracy Camp sounded the alarm in 1997 that women were leaving computer science in disproportionate numbers at every stage of education and academic employment, a phenomenon that she dubbed “the incredible shrinking pipeline.”4 Policy makers have flagged women’s underrepresentation as not only a gender equity problem but also an economic issue, given the importance of information technology to national economies and recurring shortages of technical workers. An extensive literature attempts to understand and ameliorate this problem, focusing variously on workplace discrimination, hostile climates in classrooms and workplaces, or the ways in which girls are discouraged from getting academic preparation in math and science.5 This book contributes a historical perspective, illustrating how gender has influenced the culture and structures of opportunity in the computing professions over time. Why were women encouraged to take up skilled computing work in the 1940s and 1950s, a period when many other technical professions did not welcome them? And given this early success, why are there not more women in the computing professions today? There are no simple answers to these questions, but the historical dynamics discussed in this book provide some pieces of the puzzle. These include widespread assumptions about technical skill that affected both women’s inclination to choose computing and their chances of being hired, differing cultural imperatives for men and women to seek and define themselves by paid employment, popular stereotypes about what computers are for and who is best suited to master them, and the organization of computing work, particularly issues of work-family balance. But this is not a story of oppression and failure: the chapters that follow highlight the bold and creative strategies of

Introduction  3

40 CS degrees Programmers

35

Percentage

30 25 20 15 10

2008

2006

2004

2002

2000

1998

1996

1994

1992

1990

1988

1986

1984

1982

1980

1978

1976

1974

1972

1970

1969

0

1966

5

Year

Figure I.1 Percentage of female employed programmers and computer science degree earners in the United States. Source: Data from U.S. Department of Labor, Bureau of Labor Statistics, Employment and Earnings (Washington, DC: U.S. Government Printing Office, 1977–1988); U.S. Department of Commerce, Bureau of the Census, Statistical Abstract of the United States (Washington, DC: U.S. Government Printing Office, 1989–2007); National Science Foundation, Science and Engineering Degrees: 1966–2006 (Washington, DC: NSF, 2008).

women who loved computing work, excelled at it, and forged successful careers. Their experiences may provide inspiration and practical pointers for current policy interventions. Gender and the History of Computing Women and gender are conceptually distinct but historically intertwined subjects. Gender is a cultural framework that defines masculinity and femininity as different and unequal. A culture’s repertoires of gender differences are internalized by individuals and shape their experience of identity. In the larger society, these supposed differences are used to rationalize power differentials and divisions of work in the home and the labor market. Although gender categories are represented within the culture as a natural expression of innate sex differences, they are in fact social constructs, and they permeate areas that are far removed from

4  Introduction

biology (for example, the notion that objectivity is a masculine trait and subjectivity is feminine).6 Gender categories are not fixed; they must be constantly maintained through the actions and interactions of individual people, and in the process they may be modified, strengthened, or challenged.7 Women and men who choose nonstereotypical career paths— the male nurse, the female engineer—can help tilt cultural expectations, broadening the boundaries of what is acceptable for each gender to do while simultaneously diversifying the types of behavior that are deemed appropriate within these occupations. Computing is a particularly good arena for examining the intersection of gender and technology. Employed as technical experts from the very beginnings of digital computing, women were inventing careers and professional identities at the same time that the field itself took shape. Their stories illustrate the power but also the mutability of gender roles. Masculinity and femininity were part of the cultural vocabulary that was used to define what a computer was and who was best qualified to use one. For example, comparing the computer to an adding machine would immediately invoke women as appropriate users; casting it as a management tool would place it in male territory. But technical engagement could also be a means for reshaping gender categories, as female programmers and computer scientists leveraged their status as professionals to fashion new personal identities that united femininity with technical expertise. Not all women were affected in the same way by gender issues, and constructions of gender varied over time and place. (For example, the British and American women I focus on were largely excluded from building computer hardware in the early years, but in the Soviet Union, where a different gender ideology prevailed, women helped design and build the first digital computer in 1951.)8 Indeed, one of the most fascinating aspects of this history is the variety of ways that women perceived and responded to gender-related opportunities and barriers, as well as the ways in which gender roles were mediated by the unique characteristics of computing as a field. Until the 1980s, women as historical actors were largely neglected in histories of science and technology, and one of the central projects of academic feminism has been to restore women’s contributions to the record.9 Any such undertaking must avoid two pitfalls. The first is writing history that is merely compensatory, adding women to an existing historical

Introduction  5

framework without questioning its categories, assumptions, and priorities—an approach that was memorably critiqued by Charlotte Bunch and Mary Hunt as “add women and stir.”10 My approach here is the opposite: I use women’s experiences as a lens to focus attention on unexamined mechanisms of gender discrimination. The second pitfall is to equate studying gender with studying women, as if men and masculine culture were gender neutral. I do not assume here that women are the only carriers of gender. Indeed, one of my aims is to ask how supposedly neutral or purely technical criteria and procedures have been infused with masculine preferences and values. In examining computer culture, do we find that male-identified personality traits, such as aggressiveness, were deemed essential for successful programming or research? Were work processes designed for someone with a man’s traditional freedom from childcare? Were there conscious efforts to associate computing with highly maledominated fields such as engineering? Or were the gender characteristics of computing more flexible and inclusive? It is possible and desirable to have studies of gender and computing that do not focus on women, but women’s stories, by their very lack of fit with expected norms, can bring into sharp relief the gendered nature of science and technology.11 The history of computing has developed a rich literature from academic, journalistic, and participant perspectives.12 Going far beyond mere celebrations of inventors or antiquarian descriptions of notable machines, historians have documented the complex social and technical evolution of machines, ideas, organizations, and events. But until recently, women were largely missing from these accounts.13 There are many reasons for this. Historians of science and technology have documented how women tend to be relegated to lower-profile positions where they receive less recognition than men with comparable talents and contributions. In computing, many women were stuck on the bottom rung of the ladder doing tasks such as punching holes in computer cards.14 Women who did make significant contributions were not always inclined, by temperament or socialization, to trumpet their accomplishments.15 Most of the books that look specifically at women have focused on a few exceptional individuals, such as Betty A. Toole’s Ada, the Enchantress of Numbers: Prophet of the Computer Age; the biographies of Grace Murray Hopper by Kathleen Broome Williams and by Kurt W. Beyer; and W. Barkeley Fritz’s account of the ENIAC programmers.16

6  Introduction

The invisibility of women also reflects a more general bias: early histories of computing largely equated computing with hardware. This narrow focus led to a relative neglect of software, theoretical computer science, and the practice of programming. Since women rarely had the chance to participate in building computers, the initial focus on hardware unintentionally biased the history of computing toward the activities of men. More recent scholarship has brought fresh attention to the history of software and programming, as well as to women’s achievements.17 These changes in the historiography of computing demonstrate how our notions of what constitutes history reflect our sense of what and who are important. Gender has clearly been one factor that has shaped that assessment. In retelling some episodes from the history of computing, this book questions, as women themselves did, some basic tenets of the field—how a software business should be run, what the norms should be for collegial interaction, and why some innovations and research contributions are valued more than others. Another emerging topic in the history of computing is labor—the often invisible efforts of the people who make the machines useful. Labor issues in the history of computing have received only patchy coverage, often by nonhistorians. In the 1970s, sociologist Philip Kraft and political economist Joan Greenbaum each produced studies in the tradition of neo-Marxist labor process theory, purporting to show that programming had been deskilled as part of a struggle for control between labor and capital.18 These claims have been criticized by historians for confusing employers’ rhetoric with reality and for ignoring the high levels of skill and autonomy that continued to characterize programming jobs.19 More recent studies have focused on the working conditions and power struggles of itinerant software contractors in a globalized, networked world.20 Among historians of computing, Thomas Haigh and Nathan Ensmenger have both considered working programmers as would-be professionals striving for influence in the corporate hierarchy.21 Scholars who combine aspects of gender and labor perspectives include David Grier, whose groundbreaking When Computers Were Human documents women’s work in the prewar hand-computing era; Marie Hicks, who argues that programming work underwent a process of masculinization in 1960s Britain; and Ensmenger, who makes a similar case about computing in America.22

Introduction  7

Many other themes remain to be explored within the labor history of programming. For example, how is the overall process of producing a program divided into individual jobs, and how are these jobs assigned to particular types of workers? Who designs the tools that programmers use in their work, and what criteria guide their designs? What attributes and tasks—mental, physical, social—are included in definitions of labor and of skill? How is excellence judged? All of these questions have an unspoken gender component that the chapters of this book bring to light. The workers I look at, programmers and academic computer scientists, were generally considered professionals, with jobs that usually required a college degree and implied a high level of technical skill. Although large numbers of women were employed in low-status jobs such as card punching, I have focused on the upper echelon of the computing field to highlight issues of skill and status and to make visible some notable contributions by women. One particularly important place where labor and gender issues intersect is in the social construction of expertise. As Judy Wajcman notes, “The classification of women’s jobs as unskilled and men’s jobs as skilled frequently bears little relation to the actual amount of training or ability required for them. Skill definitions are saturated with gender bias.”23 Competence, status, and professionalism are often defined through contrasts that our culture has laden with gender symbolism—opposing technical and interpersonal skills, mathematical and verbal aptitudes, mental and physical work, abstract and applied, or individualism and cooperation. Yet the content of these gender stereotypes is not fixed. To remain in place, they must be continually reinforced by the actions of individuals who choose (perhaps under social pressure) to follow them. Conversely, women and men can challenge gender stereotypes by choosing to act differently and by advancing new definitions of skill that value traits considered feminine. By revealing the gendered underpinnings of a variety of labor practices, I hope to move discussions of computing away from the assumption that the work itself is simply gender-neutral and toward a recognition that technical practices have historically embodied unequal power relations—but can also be reconceived in ways that promote greater justice. In addition to documentary sources, the book draws on fifty-two oral history interviews I conducted with American and British women. These

8  Introduction

firsthand accounts provide valuable insights into individual women’s motivations, choices, and satisfactions in their computing careers. I chose to study American and British women because their countries were the early computing superpowers in which many of the important milestones of hardware and software were achieved. Both countries also have a current policy goal of recruiting and retaining more women in computing, an enterprise that may be aided by knowing more about how women fared in the past. Including two countries in the study allows a comparison of women’s experiences in different political, economic, educational, and cultural contexts. Although the details of these experiences may not be generalizable to other cultural contexts, the general mechanisms by which gender shaped opportunities in computing are likely to have parallels elsewhere. The book begins with the experiences of women who worked with the earliest electronic digital computers—Colossus in Britain and the ENIAC in America. To understand the complex ways in which gender helped define programming work, I explore the interactions between the labor demands of World War II, which pulled women into technical jobs; gender roles as a constraint on women’s career options; and individual women’s own agency in choosing and successfully performing computer work. Chapter 2 examines methods for recruiting programmers in the postwar context of escalating computer use. Examining hiring practices from the 1940s to the early 1970s, I unpack the hidden assumptions about programming skill—what it was and who was likely to have it—that underlay these strategies. I note how gender stereotypes and gendered structures of opportunity constrained women’s ability to fit the profile of the perfect programmer but also how female programmers advanced their own counternarratives of skill that linked it with feminine strengths. Chapter 3 contrasts the introduction of automatic programming techniques in the 1950s with a movement starting in the late 1960s to redefine programming as software engineering. Both of these efforts to improve software production struggled with tensions between programmers and managers over the professional status of programming work, but there was a gender shift over time: the software engineering movement embodied a more masculine vision of programming, and the visibility of women as contributors declined. I examine the multiple, contested meanings of terms such as automation, crisis, and engineering to show how the choice

Introduction  9

of programming methods was also a struggle over the programmer’s professional and social identity. Chapter 4 describes the struggles and achievements of two early software entrepreneurs, Elsie Shutt and Stephanie Shirley, who started their firms at a time when software contracting was a new and risky enterprise and were able to succeed when many male-owned firms failed. Combining social and business innovation, both women pursued a remarkable mission—to provide part-time programming jobs for women who wanted to maintain their technical careers while raising a family. Chapter 5 shifts the focus to academic computer science, which became firmly established in the 1960s. Women’s career narratives illustrate both the obstacles that female scholars have faced and their resourceful strategies for gaining credentials, finding alternative ladders to visibility and career advancement and creating their own professional forums and events. These examples reveal how the professional structures and practices of computer science reflect—but could also be used to change—a gendered computing culture.

1 Breaking Codes and Finding Trajectories: Women at the Dawn of the Digital Age

I was a Colossus operator, which we considered to be the crème de la crème. We felt we were “at the sharp end,” where there was a great tension and flow of adrenaline . . . operating those incredible machines. —Jean Beech, Colossus operator1 I don’t know if you can picture how exciting the ENIAC was to all of us. And we didn’t talk socially or any other time about anything else. It was—we discussed it almost all the time. —Jean Jennings, ENIAC programmer2

During the Second World War, women like Jean Beech and Jean Jennings ventured into a wholly new field—digital computing. They were neither intimidated by the noisy, room-sized machines that they encountered nor deterred by any sense that they were entering a masculine domain. Instead, the accounts of women who worked on wartime computer projects convey a sense of excitement, fun, and pride at mastering a challenging task and contributing to the Allies’ eventual victory. This sense of the importance, high status, and sheer joy of working with computers still motivates women to choose careers in software or computer science today. Yet throughout the history of computing, the ability of women (and men) to enter and flourish in these careers has been strongly influenced by gender stereotypes and unequal structures of opportunity. This chapter uses examples from the World War II era to demonstrate how assumptions about the gendered nature of technical skill, about women’s place in the workforce, and about the nature of computing could constrain women’s options and lead to an undervaluation of their contributions. Over time, however, both gender roles and the

12  Chapter 1

meaning of computing itself—what computers are good for and what it takes to make them useful—have changed, and women have played an active role in defining both. These twin themes are explored throughout this book. Wartime Missions: Colossus and ENIAC The pressures of World War II drove a wave of technical innovation. Lives were saved or lost by developments such as radar, the atomic bomb, and the mass production of penicillin. Less known among these wartime projects are the first electronic digital computers.3 Before the 1950s, the tasks that we associate today with computers were done by an array of specialized machines. Mechanical desk calculators were used to perform arithmetic, and the people who did these calculations—often women—were called computers; this term did not yet refer to a machine.4 For business and government record keeping, there were electromechanical tabulators that sorted and tallied information that was stored on punched paper cards. Punched-card machines had been invented by Hermann Hollerith to tabulate the 1890 U.S. Census; in 1911, Hollerith’s firm became the core of a new company called IBM, which quickly dominated the business.5 Scientists sometimes did complex calculations using analog computers, which used physical motion, such as the rotation of a cylinder, to represent mathematical functions or model physical processes. Analog computers had been introduced in the 1930s, most notably the Differential Analyzer invented by Vannevar Bush at the Massachusetts Institute of Technology. A general-purpose computer that could handle all of these diverse applications did not exist.6 In addition, the prewar machines operated relatively slowly because they relied on mechanical or electromechanical components. Not until the wartime emergency did computer designers dare to build machines whose circuits used thousands of vacuum tubes—components that were considered unreliable and impractical—to operate at electronic speed. A brief survey of the invention of the digital computer shows how a series of experimental machines gradually advanced the state of the art, eventually producing a modern computer that was fully electronic (rather than electromechanical) and general-purpose (programmable). One of the first digital computers was built in Germany by Konrad Zuse; his Z3

Breaking Codes and Finding Trajectories   13

machine, completed in 1941, was a program-controlled electromechanical computer.7 Zuse’s work was little known outside of his immediate circle, however, and the Z3 was destroyed in the war. Most subsequent developments were made in the United States and Great Britain. John Atanasoff and Clifford Berry at Iowa State University built an operational computer in 1942, which was a special-purpose (nonprogrammable) electronic machine. In the UK, a series of ten electronic computers called “Colossus” were built at the top-secret codebreaking facility at Bletchley Park near London, with the first one operating in February 1944. The Colossi were theoretically programmable, but in practice they were configured for a single codebreaking task. In March 1944, the IBM Automatic Sequence Controlled Calculator, also known as the Mark I, came online at Harvard University. Designed by Howard Aiken, the Mark I’s programming staff included Grace Murray Hopper, soon to become a major figure in computing. The first fully electronic programmable digital computer was built at the University of Pennsylvania by J. Presper Eckert and John Mauchly beginning in 1943. This machine, the Electronic Numerical Integrator and Computer (ENIAC), was completed in November 1945.8 After the war, computer designers took the final step to a truly general-purpose computer by creating machines that stored their programs in software, resulting in a processor that was functionally similar to those used today. The first operational stored-program computer was the EDSAC, built at Cambridge University in 1949.9 This chapter focuses on two of these pioneering projects, Colossus in Britain and ENIAC in America. Both made important technical advances, both influenced the development of computers after the war, and both employed teams of women to operate the machines. After introducing each machine, I examine how and why women were drawn into these projects, what the perceptions and realities were of the jobs they performed, and what women’s options were for pursuing a postwar career in computing. These historical episodes illustrate how technical innovations and social expectations framed opportunities in the new computing field. I also highlight women’s agency—their motivations and constraints in choosing computer work and their accomplishments and pleasures on the job. Programming and operating computers was hard and important work, but it was not always recognized or rewarded as such when the workers were women.

14  Chapter 1

Colossus It is regretted that it is not possible to give an adequate idea of the fascination of a Colossus at work: its sheer bulk and apparent complexity; the fantastic speed of thin paper tape round the glittering pulleys; . . . the wizardry of purely mechanical decoding. —General Report on Tunny, 194510

Colossus was part of the Allied effort to read secret communications sent by Germany and Japan. Codebreaking was an essential element of wartime intelligence: if the Allies could decode Axis messages, then they could anticipate attacks and take appropriate measures. Such eavesdropping also gave the Allies feedback on whether their own plans had become known to the enemy. One of the most important Allied codebreaking operations was located at Bletchley Park, about 50 miles north of London.11 The challenge for Bletchley Park was that the Germans used a series of highly sophisticated encryption devices that defied the usual methods of decoding. The first of these German decoding devices was called the Enigma machine. In 1940, the brilliant mathematician Alan Turing built an electromechanical device called the bombe that could decode messages prepared by Enigma. By that time, however, Hitler and his high command had adopted an even more advanced technology, the Lorenz machine. This machine had ten wheels, each of which had the letters of the alphabet arranged around the rims. By changing the positions of these wheels at the start of each message, the sender could vary the way that the messages were encrypted. To reverse engineer this process, the codebreakers at Bletchley Park had to work out the logic of the machine and then determine, for each individual message, the starting positions of the ten wheels. The first step in mechanizing this process was a special-purpose electromechanical computer, built in 1942, that could simulate the actions of the Lorenz machine. Since the German cipher was code-named Fish, the Bletchley Park machine that mimicked it was whimsically named Tunny. Given correct starting positions for the ten wheels, Tunny could take an encoded message as input and quickly produce unencrypted German text as output. The question now was how to figure out the initial wheel settings.12 Mathematician Max Newman, drawing on the ideas of Alan Turing, worked with British Post Office electrical engineer Tommy Flowers to design a computer that could search for the starting positions of the Lorenz

Breaking Codes and Finding Trajectories   15

wheels. Flowers built this machine, which used 2,500 electronic valves (vacuum tubes), with a team of engineers at the Post Office research station at Dollis Hill. Coded messages were input using punched paper tape at a rapid rate of 5,000 characters per second. The room-filling computer was dubbed Colossus, and eventually a series of ten Colossi were produced, differing mainly in size (figure 1.1). The first Colossus was assembled at Bletchley Park in December 1943 and began decoding messages in January 1944. Like hundreds of other workers at Bletchley Park, the Colossus operators were chosen from members of the Women’s Royal Naval Service, known as Wrens. New Wrens recruits were given assignments based on immediate needs and interviewers’ assessments of their abilities. Those sent to Bletchley Park were not told the nature of the work until they arrived; to maintain secrecy, the Bletchley Park Wrens were officially assigned to the fictitious ship HMS Pembroke V. At the peak of Colossus operations, there were approximately sixty operators, working in three shifts or “watches.”13

Figure 1.1 Colossus operated by Dorothy Du Boisson (left) and an unidentified Wren. Photo courtesy of the National Archives, United Kingdom.

16  Chapter 1

Colossus was a boon to the Allies, allowing 13,508 messages to be decoded by war’s end. The second Colossus machine was built in a rush to have ready in time for D-Day. Put in operation on June 1, 1944, it allowed Bletchley Park staff to decode Adolf Hitler’s battle orders to Field Marshall Erwin Rommel. These revealed that Hitler had been fooled by the Allied ruse to draw attention away from their planned Normandy invasion. Hitler ordered Rommel not to shift his forces to Normandy, leaving the way open for General Dwight D. Eisenhower to attack on June 6. As the battle progressed, further details of Hitler’s plans were revealed through Colossus, hastening the Allied defeat of the German army. Eisenhower is said to have estimated that the intelligence from Bletchley Park shortened the war by at least two years and saved hundreds of thousands of lives.14 ENIAC Well, how d’you like this new knick-knack, The Wonderful Answering ENIAC? With thirty tons of mechanical brains, It multiplies, adds, divides, explains. —“Ode to the ENIAC,” 194615

On the other side of the Atlantic, the U.S. Army was exploring the use of machines to tackle a very different problem—ballistics calculations. Faculty at the University of Pennsylvania’s Moore School of Electrical Engineering had been assisting the army’s Ballistics Research Laboratory, at Aberdeen Proving Ground in Maryland, to determine the trajectories of projectiles fired from various weapons. Some calculations were done on the Moore School’s Differential Analyzer, while others were done by two hundred female computers who were trained in mathematics and used desk calculators. The goal was to compute firing tables, which showed gunners how to aim their weapons to hit a target at a particular range. The calculations needed for such a table were complex. To create a single firing table required a month of continuous work for either the Differential Analyzer or a team of a hundred women.16 Moore School professor John Mauchly proposed to speed up this process by building an electronic digital computer to do the calculations. In 1943, Mauchly and his colleague John Presper Eckert received a contract from the army to build the ENIAC. Like Colossus, the ENIAC used

Breaking Codes and Finding Trajectories   17

vacuum tubes—18,000 of them—to perform calculations, making it the first fully electronic computer in the United States (figure 1.2). To program the ENIAC, the army recruited a team of six women. The original programmers were Jean Jennings (Bartik), Betty Snyder (Holberton), Frances Bilas (Spence), Kay McNulty (Mauchly Antonelli), Marlyn Wescoff (Meltzer), and Ruth Lichterman (Teitelbaum).17 Several additional women worked on the ENIAC after it was transferred to Aberdeen in 1947. The ENIAC was completed and ran its first program in November 1945—too late to help in the war effort but just in time to influence the postwar computer industry. One of its major tasks while still at the Moore School was a set of calculations that modeled thermonuclear bombs in 1946. It was then moved to Aberdeen, where it began operation again in July 1947 and continued to be used until 1955.18 Eckert and Mauchly left Penn after the war to start their own company, developing a series of government and commercial computers including the highly successful UNIVAC.

Figure 1.2 ENIAC computer, 1946. Photo courtesy of University of Pennsylvania Archives.

18  Chapter 1

Computer Work and the Gendered Division of Labor By the time I reached my third year of college, I started looking around for some type of occupation that could use a math major. I didn’t want teaching. Insurance companies’ actuarial positions required a master’s degree (and they seldom hired women, I later found out). . . . Just after graduation, I happened to see an ad in the daily paper. The Army was looking for women with a degree in mathematics—right here in Philadelphia. —Kay McNulty, ENIAC programmer19

How did women come to staff the world’s first electronic digital computers, a seemingly masculine engineering domain? The short answer is that they were actively recruited during a time of urgent need and scarce male labor. The contributions of Rosie the Riveter and her like are well known: the American and British governments exhorted women to take wartime production jobs, and millions of women filled blue-collar factory positions that formerly were the domain of men.20 Just as women were recruited for jobs in the aircraft industry, so they were also channeled into computer jobs that might otherwise have gone to men. But invoking wartime labor scarcity begs the question because labor scarcity is not a given fact, it is a social construction that depends on assumptions about what types of people are suitable to fill which types of positions. Other solutions to the problem of supplying both fighters and workers were certainly possible. Why not allow women to serve in combat so that men could keep their existing jobs? Why not recruit black men for skilled wartime jobs instead of confining them to the lowestpaid work? These alternatives would have been unappealing, even unthinkable, to most political and business leaders (and women themselves) because the same cultural attitudes, priorities, and power relations that had excluded women and minorities from certain occupations before the war were still in play.21 As historian Jennifer S. Light has argued, “the meaning of ‘wartime labor shortage’ was circumscribed even as it came into being”; it did not lead to having large numbers of women promoted into the “more ‘important’ technical and classified work” reserved for men.22 At midcentury, the segregation of labor markets by sex was an open, legal, and ubiquitous fact of life in the United States and United Kingdom. Women who wanted to join the military were shunted into auxiliary noncombat groups such as the WAC (Women’s Army Corps of

Breaking Codes and Finding Trajectories   19

the U.S. Army), the WAVES (Women Accepted for Voluntary Emergency Service of the U.S. Navy), and the WRNS (Women’s Royal Naval Service of the UK Navy, popularly known as “Wrens”). Women were accepted in “men’s” production jobs only with the understanding that they would vacate these positions after the war to restore the accustomed gendered division of labor. Yet the many constraints on women’s options did not prevent some from actively choosing computer jobs, whether as a career path, a brief adventure, or a patriotic duty. It is worth asking what made computer work seem possible and desirable for these women. In other words, what defined this type of work as a good opportunity rather than something unimaginable or unappealing? This question resonates with today’s efforts to recruit more women into computing, as it has become clear that the mere existence of computer jobs and the lack of explicit gender barriers do not automatically translate into having women regard these jobs as attractive opportunities. The historical cases suggest that important factors include whether the skills that women already possess are seen as relevant for computing and how computer jobs compare to more familiar alternatives for women. In the World War II context, one factor that encouraged women to consider technical work was government efforts to recruit them into factory jobs. Billboards and slogans recast technical work—formerly off-limits as a masculine area—as appropriate and manageable for women, assuring them, “If you’ve used an electric mixer in your kitchen, you can learn to run a drill press.”23 At the same time, the limited careers that were open to women in more traditional fields made computing seem a promising alternative. Before the war, American and British women with a college degree or other advanced preparation in math found themselves tracked into low-paid jobs with little hope of advancement. Typically, they were hired either to teach math in secondary school or to do tedious repetitive calculations for insurance companies or other information-intensive businesses. Many women, like McNulty quoted above, found neither choice appealing. For them, a job in scientific computing presented one of the more exciting and well-paid opportunities that a mathematically inclined woman could hope for in the mid-1940s. As in other areas, women’s roles in wartime computing projects were circumscribed by the existing gendered division of labor. Designing computer hardware was done solely by men, since women were excluded

20  Chapter 1

from gaining the engineering education, experience, and authority that might have allowed them to participate. Women’s only involvement in building the ENIAC hardware was performing factory-like assembly of components.24 On the other hand, operating and programming computers could more easily be constructed as women’s work. Since the jobs of computer operator and programmer did not exist before the war, they were not already stereotyped as masculine. Moreover, women had their own prewar history in computing that gave them entry—within limits— to new computer projects. In the scientific world, women had been employed in large numbers to do calculations by hand. These human computers generally, although not always, had some training in mathematics, and it was from the ranks of such mathematically trained women that the ENIAC project drew its first corps of programmers. However, even women with college degrees were relegated to subprofessional job classifications. As Kay McNulty recalled, “The girls were told that only ‘men’ could get professional ratings.”25 The ENIAC programmers were not promoted from computer to mathematician—a professional rating—until January 1946.26 In the separate world of administrative data processing, women typically held the low-level job of key-punch operator (the person who punched holes in the paper cards used for input) or the slightly more advanced job of tabulating machine operator (the person who loaded decks of cards into the machine and initiated its operation). The existence of female tabulator operators may have provided a precedent for employing women as computer operators at Bletchley Park. Because of the particular role that the computer played at Bletchley Park, the Wrens were not called on to become programmers as the ENIAC women were. Although the Colossi could, in theory, be programmed for a variety of tasks, in practice they were devoted to codebreaking, and Bletchley Park had no programmers as such. Instead, the work of programming was divided between a mathematician, who decided what operations the machine should perform to solve a given decoding problem, and an operator, who used the mathematician’s instructions to set up and run these operations on the computer. Dividing the task this way was meant to conserve the scarce labor of trained mathematicians. It also reproduced a gender hierarchy: all of the cryptographers working with Colossus were men, and all of the operators were women.27 As B. Jack Copeland notes in his history

Breaking Codes and Finding Trajectories   21

of Colossus, “In those deeply sexist times no woman rose to a senior management position in the Newmanry [the Colossus area, named after Max Newman], and none achieved the status of cryptographer, despite the fact that nine per cent of Newmanry Wrens had received a university education” (and this at a time when only 4 percent of British men had earned college degrees).28 The wartime computing environment presented women with a complex mixture of new opportunities and old gender boundaries. Women’s Entry into Wartime Computer Projects: Motivations and Experiences The Bletchley Park Wrens were not necessarily looking for technical work. Indeed, they had no way of knowing about the computers, whose existence was kept secret. The women had volunteered for a variety of personal reasons, including a desire to help with the war effort or a wish to leave the confines of home or a dull job. Yet becoming a Wren was still a significant choice. Joining up meant committing oneself to leave familiar surroundings, submit to military discipline, and work under grueling conditions. 29 For women already willing to take on these challenges, mastering an unfamiliar machine may have seemed more intriguing than intimidating. Eleanor Ireland, a newly recruited Wren in September 1943, recalled being eager for a chance to operate Colossus after she caught a glimpse of one: “I was transfixed by it. All these whirring tapes . . . and the noise of it all. . . . I was fascinated by it. . . . I thought, now that’s where I’d like to be, not doing the other things. I wanted to be on that machine.”30 As a Wren, however, she had no real say in her assignment, other than by doing her best on the placement test that was used to pick which women would operate the most complex machines. The work environment at Bletchley Park was both exciting and harsh. Material conditions were often unpleasant due to wartime shortages; many Wrens complained about the sweltering heat of the machine rooms in summer and the bitter cold of the dormitories in winter. “The food was pretty grim,” recalls Ireland; “To be faced with cold congealed liver and prunes in the middle of a night watch was not very good.” The workers were also subjected to military discipline—although as with many aspects of life at Bletchley Park, there was a gendered double standard. Male mathematicians recruited for the project from Oxford or Cambridge

22  Chapter 1

“remained in civvies, independent of the demands of army life, thus having freedom for conscientious research and overtime, a deciding factor in favor of original thought and good work.”31 While men’s supposedly more creative work excused them from military exercises, Colossus operator Catherine Caughey described how the Wrens were forced to do drills and marches after working all night on the machine: “They made us do an hour’s squad-drill on the gravel in front of the Abbey every morning. . . . We were all being killed by the constant changes of shift. Church Parade on a Sunday was compulsory. On my first Sunday, when I was on nights, I had to assemble with the others. We had to march two miles each way to the village church, along an icy road.”32 The arduous and seemingly unnecessary demands placed on the Colossus operators reveal their superiors’ unspoken presumption that women’s work is by nature mundane and does not require one’s full energies. Such gender stereotyping can be destructively self-fulfilling. With their work seen as less important, women are loaded down with extra chores such as military drills (or in the present day, housework or low-level administrative tasks). These burdens, in turn, make it harder for women to perform up to their potential, reinforcing the idea that they are less capable than men. In the Bletchley Park case, there was a somewhat happier ending: those in charge of the Colossi eventually noticed the exhaustion of their operators, and they told the Wren officers to stop requiring the two-mile march to church.33 Like all personnel at Bletchley Park, the Wrens had to observe strict secrecy, given the highly sensitive nature of their work. New recruits to Bletchley Park had to sign the Official Secrets Act and were threatened with dire consequences should they ever breathe a word about the codebreaking operation. All personnel were forbidden to talk about their work, to keep diaries, or to tell their families what they were doing— either during the war or long afterward. Despite all this, many women found the social environment one of freedom, adventure, and independence. They had a chance to escape parental supervision, go to London on their days off, mingle with people of other social classes, and find romance; many women married men they met at Bletchley Park. And the work, however tedious, was made meaningful by their awareness that they were performing a vital (if mysterious) service for their country. For the Colossus operators, there was also the thrill of working with cuttingedge machines.

Breaking Codes and Finding Trajectories   23

In contrast to the Wrens, the ENIAC women in Philadelphia made an explicit choice to work with a computer—although neither they nor anyone else at that time had a clear idea of what that would involve. Some of them had already been working for the military doing hand calculations; others came straight from school, having found out about the openings at the University of Pennsylvania through college advisers or friends. One thing that they had in common was a dearth of better options. Kay McNulty (quoted above) was painfully aware of the limited prospects for female mathematicians. Marlyn Wescoff, one of two ENIAC women with a nonmathematical college degree, found the job market even worse. She had graduated from Temple University in June 1942 as an education major specializing in social studies, English, and business but could find no teaching jobs in those areas. Hoping to make the most of what skills she had, Wescoff sought out a position at the Moore School: “Late in August of that year a friend told me they were hiring at the Moore School and if I knew how to run a calculator, that would stand me in good stead. I made an appointment for an interview with John Mauchly, but he quickly turned me over to his wife, Mary, who hired me when informed that I could operate an adding machine.”34 Jean Jennings, who had been doing desk calculations for the army at the Moore School, recalled how she jumped at the chance to train as an ENIAC programmer instead: “It was something new! I mean, I didn’t know what it was, but I knew that it was boring sitting there and pounding the calculator, and [ENIAC] was something new. And I always believed that I could do anything as well as anybody else, if I were on an even footing.”35 Jennings’s reaction reflects an awareness that the “computer” positions traditionally held by women were dead-end jobs with little chance for promotion. Since she planned to continue working after the war, she hoped to get in on the ground floor of a new profession where she could be “on an even footing” with men. The ENIAC project had a much more relaxed atmosphere than Bletchley Park. Security was still a factor: there were restricted areas, and applications such as the hydrogen bomb calculations were kept secret from the women. But the programmers were allowed to talk about their work among themselves and with the engineers, and they were encouraged to learn as much about the machine as possible and to devise new techniques for programming it. Like the Colossus women, the ENIAC women also found adventure and independence in their wartime work. Women from

24  Chapter 1

small towns got to see Philadelphia, New York, and Washington, and several of them married men they met at Penn or Aberdeen. In addition, they enjoyed the intellectual challenge of the project, which gave them a chance to use their mathematical and logical ingenuity to the fullest. Constructions of Skill in Women’s Wartime Computing Work Occasionally, the six of us programmers all got together to discuss how we thought the machine worked. If this sounds haphazard, it was. The biggest advantage of learning the ENIAC from the diagrams was that we began to understand what it could and what it could not do. As a result we could diagnose troubles almost down to the individual vacuum tube. Since we knew both the application and the machine, we learned to diagnose troubles as well as, if not better than, the engineer. —Jean Jennings, ENIAC programmer36

Unlike prior women’s work, such as hand calculations, programming and operating computers were completely new tasks with unknown demands. No one had ever operated an electronic digital computer before Colossus. Although programming of the Harvard University Mark I had started in May 1944, the ENIAC women had no knowledge of this project, and in any case the procedures for programming ENIAC were completely different. Even the men who built and oversaw the computers did not have a clear idea of what would be involved in using them. Since the role of programmers and operators was not well understood in the early years of computing, gender stereotypes partially filled this vacuum, leading many people to downplay the skill level of women’s work and its importance to the computing enterprise. A review of the Colossus and ENIAC projects reveals that in both cases, project leaders underestimated the level of training needed and skill exercised by their female staffs. But even though gender bias played a large role in shaping women’s responsibilities and rewards in the workplace, this role was mediated by the open-endedness of the technology itself. Computers were new and complex enough that the work of programming them could be organized in many possible ways and their personnel could extend the boundaries of their jobs to incorporate new skills. The interaction of evolving cultural constructions of both computing work and gender could result in either a familiar pattern of sex-typing (as happened at Bletchley Park) or an unexpected opportunity (for the ENIAC women).

Breaking Codes and Finding Trajectories   25

Initial Assumptions about Computing Work The selection criteria and job training for Colossus and ENIAC indicate that these tasks were believed to require at least some mathematical ability and that the best available female workers were assigned to the computers. Wrens were placed in Max Newman’s mechanical codebreaking section based on an eclectic mix of technical and social qualifications: “Wrens were chosen by interview. . . . No fixed qualifications were required, though a pass in mathematics in School Certificate or apparently ‘good social recommendations’ was normally considered essential. .  .  . None had studied mathematics at the university.”37 Newman gave prospective operators a two-week course covering binary math, the teletype alphabet code, and machine operation, after which they were given a written exam. Those with the highest scores were given the most challenging assignments, including Colossus.38 The first Colossus operators were presumably trained by Newman himself to use the machines, but after that experienced operators took on the responsibility of training new recruits, adding another dimension to their duties. Qualifications were higher for ENIAC. The six programmers all had college degrees, four of them in mathematics, and the women passed through two levels of selection—first as hand computers and then as programmers. The level of skill involved in hand computing can be gleaned from a description of the Moore School’s 1942 training course for those who were working on ballistics problems. Students were expected to begin at a fairly high level: the course was aimed at college graduates with at least a year of college math (although later this requirement was dropped), and prospective students had to pass an aptitude test and go through an interview. The course ran for thirteen weeks, forty hours a week, including three lectures per day as well as five hours of “supervised study, the latter to include 4 hours per week of supervised laboratory work with computing machines.” Topics covered included algebra, trigonometry, analytical geometry, calculus, interpolation, exterior ballistics, and least squares.39 Much of the teaching was handled by Adele Goldstine, a trained mathematician and the wife of Herman Goldstine, the army liaison to the ENIAC project. Marlyn Wescoff (who, as noted above, had been hired on the strength of her familiarity with adding machines) described the class as challenging but rewarding: “I had not taken mathematics in college, so all of this was wonderful, strange, difficult, and exciting.”40 There was a second round of selection for ENIAC

26  Chapter 1

programmers, with Herman Goldstine picking “six of the best computers” for the job.41 Those chosen were sent to Aberdeen in June 1945 to be trained on the IBM input/output equipment to be used with ENIAC (“tabulator, sorter, reader, reproducer, and punch”).42 Despite all this preparation, the ENIAC women were not given any specific training in programming—a telling omission. As noted earlier, gender bias was certainly at work in the official classification of the ENIAC women’s jobs as “sub-professional.” However, I suggest that Mauchly and Eckert themselves did not devalue programming so much as overlook it, consumed as they were with the challenge of building a working machine in time to aid the war effort. Rather than having a clear image of programming as merely clerical, as some historians have argued, the ENIAC designers seem to have had only the vaguest notion of what programming might involve.43 As Mauchly explained in a 1973 interview, programming was an afterthought: “We didn’t think that we should spend our time worrying about figuring out programming methods and programming aids and all that. We felt that if we had the machine capable of doing all these things . . . there would be time enough to worry about those things later.”44 For the ENIAC women, the undefined nature of their job was challenging, but it also gave them the freedom to define programming—through their actions and achievements—as a wide-ranging and intellectually fulfilling task. Actual Challenges of Operating and Programming the First Computers Colossus was used for a single purpose—to discover the starting wheel patterns that the Germans used to encode particular messages on the Lorenz machine. To start a decoding cycle, the male cryptographer (seated at a desk) proposed a wheel pattern to try, and the female operator (standing at the machine) programmed that pattern into the machine by inserting pins into a grid on the back. She then prepared to run the machine by threading a tape containing an encoded message onto the computer’s tape reader, which was mounted on a large metal frame nicknamed “the bedstead”45 (see figure 1.1). The tape reader had multiple pulleys to enable it to handle message tapes of different lengths, and the operator had to adjust the tension on these pulleys to keep the tape running smoothly. Once the computer was turned on, the tape sped through the reader at 40 feet per second—which meant that if the tape broke, it went whipping

Breaking Codes and Finding Trajectories   27

across the room, endangering the unfortunate operator and bringing operations to a halt. Keeping the decoding process on track therefore depended on the Wrens’ mechanical ingenuity, and as Ireland noted, they keenly felt this responsibility: “That was a tricky operation, getting the tape to the right tension. . . . We were terrified of the tape breaking should the tension be wrong. Breaks meant that valuable time was lost. . . . It was instilled into us that time was of the very essence. We knew we were working against the clock and that people’s lives depended on what we were doing.”46 The operators also had to devise methods for keeping the tapes in good repair, as Dorothy Du Boisson recalled: “Each tape . . . had to be joined into a loop. It was difficult to get the join right, and if we didn’t the tape might not stand up to the speed of the machine. After many experiments, we found that special glue, a warm clamp, and French chalk produced a good joint—the art was using just the right amount of glue.”47 The operators did not need advanced mathematics, but they had to be able to do basic arithmetic quickly and accurately in their heads. To check whether the decoding was successful, the operator set switches on the front of the machine to program it to count the frequency of certain letters. These counts were printed out on a nearby typewriter. If the cryptographer chose the wrong wheel pattern, the results had no particular pattern of letter usage, but if the correct wheel pattern had been found, the output had a nonrandom pattern that was characteristic of the language being used (in this case, German military language).48 The operator might be asked to check whether the letter frequencies that were recorded on the typewriter deviated significantly from a given norm, signaling a possible success. Ireland recalled, “Sometimes I was given a norm, and as each figure came up on the typewriter, I did a calculation and wrote down against the figure how much above or below the norm it was. I became very good at mental arithmetic.”49 To be a successful Colossus operator therefore required physical endurance, mechanical aptitude, attention to detail, and the ability to memorize codes and do mental arithmetic. Female operators were also entrusted with a certain amount of initiative. They did some runs without supervision, evaluating the results to determine if the correct wheel setting had been found.50 They were also trained by the engineers to do routine testing of the machines, and they solved some minor mechanical problems,

28  Chapter 1

such as keeping the typewriter from shaking out of position due to the machine’s vibrations.51 Despite the various physical and mental abilities that they employed, Wrens were not treated as skilled workers or expected to understand the logic behind the machine’s operations—at least at first. The organization of work at Bletchley Park made a sharp distinction between men, who were rotated among tasks to give them a broad knowledge of the codebreaking operation, and women, who were confined to narrow tasks on the assumption that they had only limited technical abilities. As the official 1945 report noted, “Wrens (unlike men) were organised in fixed watches and given fixed jobs in which they could become technically proficient.”52 But the assumption that women’s work was by definition unskilled did not reflect the reality of the work. By 1944, it had become evident that the Colossus operators’ tasks were more challenging than their male supervisors had originally thought. As the Wrens were asked to perform more complex operations and to work unsupervised, they needed more theoretical knowledge, and in January 1945 Newman’s section set up an Education Committee (composed mainly of Wrens) to arrange technical seminars. The report conceded, “In practice it became increasingly hard for Wrens to get a complete picture of an organisation in which they might have only done one job. Moreover the mathematical style of the Research Logs made them unreadable for Wrens, and before they (or new men) undertook chi-breaking and Colossus-setting on their own, some other introduction to the theoretical side was needed.” The Colossus operators’ seminars were evidently fairly advanced, as the report contrasts them with “the less mathematical general lectures.”53 At least one contemporary witness believed that gender bias had led to an underestimation of the complexity of the women’s work. Several U.S. Army signal intelligence officers were stationed at Bletchley Park, and the first of them to work in Newman’s section, George H. Vergine, wrote a section of the 1945 report. Vergine explicitly critiqued the gendered division of labor on Colossus, arguing that stereotyped assumptions about skill had delayed making full use of the Wrens’ talents: The structure of the organisation was built on the concept that the male members should carry the responsibility for any decisions and the work should be reduced to a routine so that the Wrens were able to do it. . . . Perhaps the main fault of the organisation was that the primary principle of the difference between a man’s

Breaking Codes and Finding Trajectories   29

work and that of a Wren was overdone. . . . When the section grew to such an extent that there was a shortage of males[,] some of the Wrens did wheelbreaking jobs and other tasks requiring technical knowledge which were previously thought possible only by a man. A programme of training Wrens in theory and the work began in earnest [in January 1945,] but if this change in policy had started earlier greater dividends would have been noticed in the results.54

Vergine’s forthright critique highlights how security concerns reinforced a social hierarchy based on gender to restrict women’s roles to a degree that even their male supervisors found detrimental. It also highlights the difference in approach between the Colossus and ENIAC projects. Perhaps the Colossus operators could have developed a comparable level of autonomy and expertise as the ENIAC programmers if they had received similar encouragement to learn about the machine and to experiment with programming techniques. Like Colossus, ENIAC was set up by plugging in wires and setting switches (figure 1.3). The various components of ENIAC had to be laboriously reconfigured for each calculation, in effect building a new specialpurpose computer each time. As with Colossus, operating the machine was very much a hands-on, physical activity—but unlike Colossus, this was only the last stage of the women’s programming process. It began with numerical analysis—taking a mathematical problem and converting it to a form that could be solved using the arithmetical and logical capabilities of the computer. Then the program had to be broken down into a sequence of detailed steps, and finally these steps had to be converted into instructions for setting up the machine. Only then did the women do the physical setting up and finally run the program. Since most programs do not run perfectly the first time, the programmers usually needed to debug the instructions and repeat the cycle until they achieved the desired results. The first problem run on the machine was a calculation for the hydrogen bomb. It was devised by physicists Stanley Frankel and Nicholas Metropolis, who came to Philadelphia from Los Alamos for this purpose. For this problem, Herman Goldstine taught Frankel and Metropolis how to specify a program for ENIAC, and the female programmers used these specifications to set up the program on the machine. For subsequent projects, however—including the ballistics trajectory calculations for which the machine had been built—the women performed the mathematical analysis and logical design of the programs as well as the physical setup

30  Chapter 1

Figure 1.3 ENIAC with Frances Bilas and Jean Jennings. Photo courtesy of University of Pennsylvania Archives.

and subsequent debugging. This diverse set of tasks required advanced mathematics and a detailed mastery of the machine’s logical design and its physical layout, as well as creativity, initiative, and physical endurance. As noted above, the ENIAC women were offered no instruction in programming (indeed, no one was qualified to teach it), and no manuals were available until Adele Goldstine produced one in June 1946, well after the original programmers had trained themselves.55 The women learned by trial and error, discussing ideas among themselves with little more than engineering drawings to guide them.56 Jean Jennings recalled that only after she and Betty Snyder had met Mauchly by accident were they able to enlist his help: We were sitting there, trying to figure out how the accumulator worked, and this man walked in. . . . He said, “I’m John Mauchly.” We said, “Oh my God, are we glad to meet you!” [She laughs.] We’d never met him before. . . . So he came over and helped us figure it out. He said, “Well, look, my office is right next door. When you have any problems, you can come in, and I’ll help you.” So we began to save up our problems, and in the afternoon, if he was there, we would go in and ask him all our questions. So that’s how we learned how to program the ENIAC.57

Breaking Codes and Finding Trajectories   31

In Jennings’s account, the women continued to take the initiative in formulating programming methods, with Mauchly simply answering questions that they brought to him. As noted earlier, the intellectual sophistication of programming was belatedly recognized in early 1946, when the ENIAC women were promoted to professional status in the U.S. civil service. Yet the assumption that women’s work must be less scientific or complex persisted for many years afterward. In 1971, as part of a patent dispute between the ENIAC creators and rival inventor John Atanasoff, the ENIAC women gave depositions in which they were asked to characterize their work as programmers. These documents provide a valuable glimpse into the women’s own understanding of their technical role at a time when the ENIAC was still fairly obscure and its programmers were not self-consciously claiming a place for themselves in history. Their experience of the work as novel and intellectually demanding contrasts with the male interviewer’s evident assumption that the women had merely been rote operators. Asked to define their job, the ENIAC women’s responses made a clear distinction between the physical “setting up” or “plugging in” (what we would now call operating) and the more intellectual work of numerical analysis and program design. Kay McNulty replied, “I should say that the programmer’s principal job is to reduce the equations to forms that can be used by the ENIAC and to plan the setup. By virtue of the nature of the ENIAC itself—no other machine is like this—we had to do this physical labor, which certainly wasn’t programming, the physical setting up.”58 When the interviewer tried to characterize the work as merely plugging in cords, Ruth Lichterman was quick to correct him: Q:  When you say you programmed the machine, did that mean physically that you took these plugs from one place and plugged them into another place? [Ruth Lichterman]:  Well, now, program means several things. .  .  . You got a problem, and you started with pencil and paper, and you decided how you were going to do this problem and which numbers went where. . . . [Y]ou drew a diagram of all this stuff and then you actually went on the machine, and we call that “plugging in” rather than “program.”59

Lichterman’s response describes the programmer handling the entire spectrum of tasks that were required to go from a problem statement to a logically worked out program that was ready to be “plugged in” to the machine. This work was complex and varied enough that the women specialized in different areas, according to a later account by Jean Jennings: “Betty and I were the workhorses, finishers, tying up all the loose ends.

32  Chapter 1

Kay was often more creative, suggesting clever ways to reuse and reduce the total size of the program. Marlyn and Ruth agreed to generate a test trajectory, calculating it exactly the way the ENIAC was to do it so we could check the detailed steps once it was on the ENIAC.”60 Designing programs for the ENIAC took considerable creativity, since every programming technique had to be worked out for the first time. The women made a number of innovations in programming methods. Betty Snyder is credited with inventing break points, a debugging technique that involves stopping the machine in the middle of a program to check intermediate results.61 Break points have since become a standard debugging tool. The women also developed a system of programming notation that allowed them to visualize the multiple simultaneous operations that the computer performed at each step of executing a program. With this notation, according to Jennings, “we could keep track of the timing of program pulses and digital operations. The ENIAC was a parallel machine, so the programmer had to keep track of everything, whether interdependent or independent.”62 The programmers also developed new methods in numerical analysis.63 For example, a fundamental concern in applied mathematics is that for many problems, the computer calculates an approximate rather than exact solution, which can lead to significant errors. The ENIAC women responded to this challenge by creating experimental programs to generate knowledge about the magnitude of these errors and ways to minimize them. As Jennings described in 1971, “We ran a number of problems to find out how to use the machine, to test what interval of integration gave us the most accuracy if you considered round-off error and truncation error, and we were trying to determine what interval we could use in order to minimize the effects of truncation error without building up the round-off error. . . . The view was to establish some procedure that gave us the most overall accuracy.”64 As this example illustrates, the ENIAC women took the initiative to create programming tools as well as programs. In addition to the various programming methods that the women invented, Snyder and Jennings created an important software product—the program to calculate ballistics trajectories, which had been the original goal of the ENIAC and would be the centerpiece of its public debut in 1946. Jennings described the excitement of being responsible for such a high-stakes project: “We worked nights and weekends. . . . Betty and

Breaking Codes and Finding Trajectories   33

I felt the tremendous pressure to make this thing work. Everybody was counting on us: the BRL, the Moore School, the ENIAC design group, the Goldstines. We both loved the attention and knew we could do it!”65 By the night before the demonstration, there was only one major bug left, but it was an embarrassing one: the trajectory program kept going after the projectile was supposed to have hit the ground. As Jennings recalled, “During the night it came to Betty what was wrong. She came in the next morning and flipped one switch on the master programmer and the problem was solved. Actually, Betty could do more logical reasoning while she was asleep than most people can do awake.”66 But when it came to getting credit for their accomplishment, the women were in for a rude awakening. Constructing Opportunities for Women in Computing at War’s End We had to sign the Secrets Act when we left, and we had to take all these machines down. My parents never knew what I did, and neither did my husband. I never told anybody at all. None of us ever did. —Eleanor Ireland, Colossus operator67

What opportunities were open to women in computing after the extraordinary circumstances of war gave way to the social norms of peacetime? Historians such as Alice Kessler-Harris, Ruth Milkman, and Penny Summerfield have described how British and American women who took “male” jobs in factories during the war were expected to give them up afterward to men who were returning from military service.68 Many defense projects—including hand-computing tasks that employed hundreds of women—were closed down at the end of the war, so the jobs themselves vanished.69 This was not unexpected. When the Moore School recruited women to do ballistics calculations in 1942, its advertisements warned, “It should be understood by each prospective employee that the appointment is an emergency war service appointment, which in all probability will terminate with the end of hostilities.”70 Compared with most women in wartime industries, however, the ENIAC programmers had considerably more opportunity to stay in the field after the war. There was no preexisting male workforce to push them out, and as digital computers became commercialized after the war, the demand for programmers

34  Chapter 1

increased. In this labor market, women with computer experience could potentially find well-paid and interesting jobs. Women in both the ENIAC and Colossus projects demonstrated that they had the interest and ability to excel in computing work, but their outcomes were very different. The Wrens’ jobs abruptly ceased with the end of hostilities, and none of the Colossus women seem to have pursued postwar civilian computing careers.71 In contrast, the ENIAC women had the option to continue working, and some of them went on to have distinguished and influential careers in computing. As these different outcomes suggest, gender bias was one only factor affecting women’s postwar opportunities. Several other characteristics of the American and British projects—including secrecy, divisions of labor, and training practices—affected women’s chances for making their wartime work the basis for a long-term career in computing. For all its importance, Colossus and the rest of the Bletchley Park operations remained unknown to the public for many decades. At war’s end, Winston Churchill—fearing that the technology could be used by an enemy in a future war—ordered the Colossus computers to be destroyed.72 Only many years later, when the publication of some declassified documents revealed the secrets of Bletchley Park, did the machines and their inventors and operators begin to receive credit for their crucial wartime role. Today Bletchley Park is a museum and features a rebuilt, working Colossus (figure 1.4).73 The extreme secrecy of the Colossus project hindered both men and women from reaping the full benefits of their work. The Wrens were prohibited from even mentioning to a prospective employer that they had had experience with computers. Tommy Flowers and his engineers at Dollis Hill received neither credit for their extraordinary contribution nor support for building the next generation of computers at the Post Office, which they might have been granted had their wartime achievements been known.74 In contrast, the men working on the more theoretical side of computing—Max Newman and Alan Turing—were able to put their experience to immediate use following the war. Alan Turing went to work on the Automatic Computing Engine (ACE) project at the National Physical Laboratory, drawing up plans for a stored-program electronic computer in late 1945. These plans were much more complete and specific than the largely abstract EDVAC Report authored by John von Neumann a few months earlier, reflecting Turing’s firsthand experience

Breaking Codes and Finding Trajectories   35

Figure 1.4 Former operator Eleanor Ireland with rebuilt Colossus at Bletchley Park, 2001. Photo by author.

with Colossus. Newman went to Manchester University, where he helped design the first Manchester computer, known as the “Baby.”75 As noted academics, these men possessed the intellectual authority to lead computing projects even without credit for their wartime work, and they were able to apply knowledge that they had acquired from the Colossus project without having to specify the source of their inspiration. Limited training also blocked women from moving on from Bletchley Park to computing careers. Few of the women who operated Colossus had mathematical backgrounds, and the gendered division of labor and security-driven compartmentalization of knowledge at Bletchley Park kept them from gaining theoretical knowledge of how the computers worked. Also, there was no direct commercial spinoff from the Colossus machines (as there was from ENIAC), so the operators could not translate their machine-specific hands-on skills to a peacetime job. For the Moore School women, all of these factors were reversed. They had been encouraged to learn every aspect of the machine’s design and operation and had been given mathematical training. ENIAC itself was not destroyed like the Colossi. Instead, it was transferred in January 1947

36  Chapter 1

to the Ballistics Research Laboratory at Aberdeen, where it was used until 1955. At least seven additional women became ENIAC programmers at Aberdeen.76 Most important, in March 1946 Eckert and Mauchly formed the Electronic Control Company (soon renamed the Eckert-Mauchly Computing Corporation) to commercialize their invention. ENIAC programmers Betty Snyder and Jean Jennings immediately joined the new company, which was bought by Remington Rand in 1950 and produced the very successful UNIVAC computer. The ENIAC women who did not stay in programming were constrained more by social convention than by the job market. Most remained in their jobs for a year or two after the war but then left voluntarily to marry or have children. Marlyn Wescoff left the group in December 1946 to be married. Frances Bilas, Ruth Lichterman, and Kay McNulty continued to work with the ENIAC after it was moved to the Ballistics Research Laboratory. Bilas left in 1948 when she was expecting her first child, McNulty left the same year to marry John Mauchly, and Lichterman left after two years to get married. None of the four returned to full-time computing work, though McNulty assisted informally with her husband’s business ventures. Although women of the 1940s felt some pressure to conform to the role of full-time wife and mother, marriage was not necessarily a bar to continued work as a programmer. Snyder married John Holberton (who had been put in charge of ENIAC operations in June 1945) but continued to work as a programmer and software researcher until 1983. Jennings followed a different path, pursuing full-time work and family serially: she remained a programmer until 1951, left to raise a family, returned to computing in 1967, and worked until 1985 as a project manager and editor of technical publications.77 Their technical training and experience gave the ENIAC women some room to negotiate a balance between traditional gender roles and new opportunities in computing. One common experience for the Colossus and ENIAC women was that neither group received public recognition for their work, either during the war or for many decades afterward. At Bletchley Park, there was complete secrecy: not even the Wrens’ families found out what they had been doing until the 1980s. At Penn, however, the ENIAC was given a showy debut in February 1946 that was well covered by the media. The centerpiece of the event was the ballistics program created by Snyder and Jennings, and the assembled reporters and VIPs were greatly impressed that a trajectory could be calculated faster than the flight of the projectile

Breaking Codes and Finding Trajectories   37

itself.78 Yet Snyder and Jennings received no attention or official recognition for their contributions, and the programmers were not mentioned in the publicity for the event—an omission some of them felt keenly. “I specifically remember not being invited to the luncheon” for the press, Jennings recalled in 1971. Snyder complained, “I wasn’t photogenic, and I wasn’t included on any of the pictures of the entire stupid thing.” Kay McNulty noted ruefully, “None of us girls were ever introduced [at the press conference]; we were just programmers.”79 It was not until the fiftieth anniversary of the ENIAC that historians rediscovered and began to publicize the ENIAC women’s contribution.80 Historian Jennifer Light has argued that the erasure of the ENIAC programmers stemmed from a more general devaluing of women’s labor in American society, concluding that “the press conference and follow up coverage rendered invisible both the skilled labor required to set up the demonstration and the gender of the skilled workers who did it.”81 This is undoubtedly true, but the public image of ENIAC also reflected a view of computing that privileged machines over people (of either sex). As Dianne Martin points out, press coverage of ENIAC depicted the computer as an autonomous “brain” that performed calculations with little reliance on humans.82 This distorted image was not simply the fault of ignorant reporters but also stemmed from the way that ENIAC was presented. Neither the female programmers nor the many male engineers who assisted Eckert and Mauchly received credit at the press conference. Yet as emphasized by Barkeley Fritz, who was one of the first male ENIAC programmers to join Aberdeen in 1948, the machine would have been worthless without the work of the programmers and engineers who came before him: “Success was achieved during this first time period largely because of the availability of a dedicated and often brilliant group of men and women who were available to make use of the new tool. These people understood the problems they had to solve. They studied and learned the characteristics of the new tool at their disposal, working around the clock when necessary. Without these skilled, dedicated people, ENIAC could not have been the initial success that it was.”83 Publicity materials prepared by the Moore School demonstrate how human labor of both sexes was subtly erased. For example, one of the “Basic Items for Publicity Concerning ENIAC” stated that ballistics calculations had been reduced from “25 man-months of expert computers’ time” to two hours on the ENIAC.84 But those two hours included neither

38  Chapter 1

the “feminine” work of preparing programs nor the “masculine” work of machine maintenance (which was substantial, as component failures were frequent in the early years of computing). The only work that is given visibility and value in the press reports is the initial machine design. Of course, to exalt hardware design as the main site of skill, creativity, and importance in computing is also to reinforce the status of what was and remains a male-dominated area. Gender stereotypes and assumptions about the nature of computers were inextricably entwined. Conclusion The ENIAC and Colossus stories illustrate a number of themes that run through this book. They explain how and why women became involved in computing from the earliest days, hinting at the appeal and rewards that were offered by these new occupations. They also show how attributions of technical expertise and the status and authority that flow from them have tended to follow social categories—specifically, gender—rather than necessarily reflecting the demands of the job. At Bletchley Park, the organization of labor reinforced gender stereotypes even when this detracted from the work itself. At the Moore School, assumptions about the nature of computing—the primacy of the machine and relative insignificance of the humans directing it—obscured the important role of the programmer and influenced how work and credit would be divided between women and men. The pioneering women of Colossus and ENIAC made the most of the opportunities that they were given, despite a culture of unequal expectations. Some of the obstacles that they faced have since disappeared. Yet gender as a set of beliefs, roles, and practices has continued to be a factor shaping the computing professions, even though the meanings of masculine and feminine have varied over time and across cultures. Likewise, the cultural meaning and power of computers, programming, and computer science have been constantly in flux, appropriated and contested by various actors. This uncertain identity has sometimes been a source of frustration for computer professionals, as the following chapters illustrate. Yet the fluidity of these two terms, gender and computing, has also left open a space for women to create their own meanings.

2 Seeking the Perfect Programmer: Gender and Skill in Early Data Processing

[Electronic data processing managers’] lack of definition of the qualifications for programmers is remarkable. No set standard of prerequisites has yet been established in most companies, and the selection of programmers is often based on the EDP manager’s intuition. —Ida Russakoff Hoos, “When the Computer Takes over the Office,” 19601

In the early decades of digital computing, programming was seen as a methodical process based on scientific principles, yet the practice of hiring programmers seemed just the opposite. From the 1950s into the 1970s, employers and industry pundits complained about the difficulty of identifying talented applicants. The comments quoted above, written by business sociologist Ida Russakoff Hoos, scolded the managerial readers of the Harvard Business Review for their lack of personnel standards for electronic data processing (EDP), as computing was commonly known in the business world. They were echoed by Elmer Kubie, who had cofounded one of the world’s first software firms in 1955. In a 1963 interview, Kubie identified “the principal problem in the industry today” as “the matching of talent with growth,” explaining that “The field has grown so rapidly that the problem of selection and training of personnel has been a rather haphazard process.”2 Surveying hiring practices in the United Kingdom, a manager for Rolls-Royce grumbled that “There is not a great deal of evidence to suggest that the selection procedures currently in use in the majority of organisations in the United Kingdom are particularly effective,” adding that many managers simply chose staff “on hunch.”3 A 1969 survey of EDP trade schools—700 of which had sprung up in the United States to meet the surging demand for personnel—voiced a common complaint among schools that “industry won’t spell out exactly

40  Chapter 2

what type of training it expects programmers to have.”4 The professional body Association for Computing Machinery (ACM) warned in a 1971 report that “personnel are occupying positions for which they are inadequately qualified,” due in part to “the lack of an understanding of necessary skills and experience.”5 As late as 1973—more than two decades after digital computers had been commercialized—the author of a study on “Cognitive Predictors of Success in Computer Programmer Training” lamented, “The aptitudes and abilities required for the position of programmer, within the computer industry, have yet to be fully studied and their inter-relationships known.”6 These experts’ ongoing struggles to define the nature of programming skill allow us to observe some of the ways in which the culture of computing is based on and contributes to structures of power and meaning in the wider society. Skill is a social construct: neither the skills required to do a job nor the skill possessed by an individual can be defined in purely objective terms. Although it is possible to identify physical, intellectual, or social abilities that are relevant to particular jobs, there is never only one way to define these requirements. Other abilities can be substituted, work processes can be reorganized, different tools can be used, and varying criteria can be applied to job performance.7 Given this flexibility, social judgments often determine which job-related capabilities are seen as necessary and which become optional or even invisible. When it comes to individual workers, assessments of skill are colored by assumptions about the capacities, interests, and appropriate spheres of action of different social groups. Since technical skill conveys power—including prestige, access to well-paid employment, and the opportunity to shape the tools used by a whole society—the dominant groups in society tend to assert their “natural” superiority in these fields. In particular, technical expertise has been an important component of masculine identity in Western culture. Male workers have at times fought to preserve their monopoly over categories of work deemed skilled, and traditionally feminine areas of expertise have often been devalued and seen as nontechnical.8 Debates beginning in the 1980s over “comparable worth” or “equal value"—the principle of equal pay for equally challenging work in male and female occupations—have exposed the near impossibility of making objective comparisons of skill levels across genders, given the entrenched tendency to devalue tasks that are performed primarily by women.9

Seeking the Perfect Programmer   41

This chapter examines hiring practices from the 1950s to the early 1970s to reveal hidden gender dynamics in computing and their consequences for women. After a brief overview of programming as an occupation, I describe the most popular strategies for recruiting programmers and show how they produced arbitrary or even contradictory constructions of skill. None of these strategies measured programming competence directly, and all were heavily laden with gendered assumptions about what types of abilities were valuable and how they could be acquired. I conclude by considering how this history can inform current debates about women’s underrepresentation in computing. Programming as an Occupation In programming work, the problems encountered vary from those which can be handled by high-school students unusually proficient in mathematics to those requiring a doctorate level of education. —“Employment Opportunities for Women Mathematicians and Statisticians,” 195610

A number of factors in the postwar decades made it hard to pin down the ideal programmer, including rapid changes in computer hardware, new application areas, fluid job categories, and an astonishing increase in demand for programming labor. With the close of World War II, computer manufacturers quickly turned their eyes to commercializing the new machines. In the United States, giant International Business Machines (IBM) competed with smaller firms such as Sperry Rand, Burroughs, and RCA, and British companies such as ICL, Ferranti, and English Electric served the UK market. Rising machine sales increased the demand for programmers. Although no reliable national figures exist for the years before 1960, an estimated 1,200 to 1,400 programmers were employed in the United States in the mid1950s.11 In 1960, the U.S. Census Bureau counted 13,000 “professional/ technical computer specialists,” and by 1970, this had soared to 163,000 programmers and 108,000 computer systems analysts and scientists—a twentyfold increase in one decade. Women accounted for 24.2 percent of these programmers (39,000) and 13.6 percent of analysts (15,000).12 Estimates for the United Kingdom range from the Economist’s figure of “about 6,500” programmers in 1967 to an industry expert’s approximation, for the same year, of 16,330 programmers and 10,160 analysts.13

42  Chapter 2

The market for digital computers was also shifting from the 1940s to the 1960s. The wartime applications had been military—codebreaking, ballistics, atomic bomb calculations—and the first postwar computers were aimed at the scientific market, including university research and calculation-intensive industries such as aviation. When a British catering firm called J. Lyons tried to buy a business computer in 1947, it found nothing suitable for sale. The company decided to build its own machine, the Lyons Electronic Office (LEO), which began running the world’s first business software in late 1951.14 By then, the computer manufacturers were aware of the huge potential market for business applications such as payroll and accounting, and they soon began supplying business-oriented machines such as the UNIVAC and IBM 650. The U.S. Bureau of Labor Statistics estimated that there were 110,000 business programmers in 1970, which would mean that approximately two-thirds of all U.S. programmers were working on business rather than scientific applications.15 Business programming involved a new set of languages (especially COBOL—Common Business-Oriented Language—introduced in 1959), techniques (sorting and manipulating large data sets, rather than performing complex mathematical calculations), and applications (such as inventory or payroll). The changing market for software added to the challenge of specifying the right qualifications for programmers. Another confusing variable was the scope of the programming task. Practitioners often divided the work of producing a program into two conceptual categories—systems analysis and programming. Systems analysis as an occupation predated digital computing; it was originally aimed at making business processes more efficient and ensuring that upper management had access to crucial information in a comprehensible form. In Britain, this was often referred to as “organisation and methods analysis” (O&M). In the context of computing, however, systems analysis meant analyzing the problem that was to be tackled—whether a missile trajectory or a payroll—and specifying a general method of solution, including what types of information would be needed as input and output from the computer. Programming then meant the detailed design, writing, testing, and debugging of the actual computer code that would turn the input provided into the required output. Systems analysis was usually seen as having greater status than programming, and jobs for systems analysts usually offered higher salaries. This status system

Seeking the Perfect Programmer   43

reproduced a long-standing Western cultural hierarchy that privileged planning over execution, as well as a gender hierarchy: systems analysts were overwhelmingly men.16 But although systems analysis and programming were conceptually distinct tasks, they were not necessarily divided into separate occupations. Many installations employed programmer-analysts who handled the entire spectrum of tasks. For example, a 1961 job ad by Reckitt & Sons (UK) sought programmers “with the emphasis on foresight and capacity to plan rather than code.”17 As is shown in chapter 3, programmers themselves often had a broader view of their work and questioned the distinction between analyst and programmer. A 1970 management text advised, “There is, in fact, quite an extensive controversy in the field as to whether systems analysis and programming are different disciplines.”18 It was up to the individual employer to decide on the local division of labor, and even then the boundaries between jobs might remain fluid. In some facilities, programmers performed not only systems analysis but operations and engineering work as well—setting up the computer, running their own programs, and troubleshooting hardware and software failures. At the other end of the spectrum were highly stratified workgroups in which senior programmers specified the overall structure of the program and junior programmers or coders wrote assigned sections of code, following the specifications handed down by the senior staff. Even then, however, such coder positions were typically regarded as entry-level programmer jobs with a promotion path to the higher ranks rather than a completely separate category of work. Job titles in the programming field were a notoriously unreliable indicator of a person’s duties or skill level, often reflecting a job’s status more than its specific content. As historian David Alan Grier has established, the use of program as a verb was not firmly established in the computer field until 1951 or so, and the derivative term programmer lagged behind.19 In 1958, the professional journal Communications of the ACM ran a series of letters to the editor bewailing the proliferation of job titles for programmers, including computing engineer, numerical analyst, data processing specialist, computer, and programmer. In response, the journal’s editor jokingly added “Flow-Chartsman, Applied Meta-Mathematician and Applied Epistemologist” to the list.20 Grace Murray Hopper, speaking from firsthand experience, also scoffed at the arbitrary titles

44  Chapter 2

given programmers. Hopper had been a math professor at Vassar College from 1931 to 1943 before joining the U.S. Naval Reserve, where she found herself assigned to program one of the world’s first digital computers, Harvard University’s Mark I. In 1949, Hopper was hired by the Eckert-Mauchly Computer Company (soon acquired by Remington Rand), where she was in charge of software development for UNIVAC. As Hopper noted in a 1968 interview, “I’ve been called an engineer, a programmer, systems analyst, and everything under the sun.” She claimed that her job title at Eckert-Mauchly, senior mathematician, was chosen primarily for status reasons: “The titles for programmers and things hadn’t been developed—they didn’t exist; and ‘senior mathematician,’ then, was sort of a combination of ‘senior programmer’ and ‘consulting mathematician’ they just landed on . . . so that I’d have a job title that . . . sounded impressive enough to match the salary.”21 A 1964 study illustrated how status considerations could distort people’s perceptions of the level of skill that was involved in various programming jobs. The study asked experienced computer personnel to distribute a list of programming tasks among a hierarchy of jobs—systems analyst, senior programmer, and programmer. The author found that “the higher the level of the job, the more job tasks which had been judged to require a high degree of skill were included”—even if some of those tasks normally were performed by workers in the lower-status jobs.22 Higherstatus workers were simply assumed to have a monopoly on skilled tasks, even by people who were familiar with the field and should have known better. We should not be surprised to find that employers, who often had no personal knowledge of programming, fell back on social categories when evaluating potential workers. Proxy Measures for Programming Skill History is filled with examples of men and women who rendered highly effective performance without the conventional badges of accomplishment in terms of certificates, diplomas, or degrees. Diplomas and tests are useful servants, but . . . they are not to become masters of reality. —Griggs v. Duke Power Company, 197123

U.S. Supreme Court Chief Justice Warren Burger’s comments on the practice of using high school diplomas as hiring and promotion criteria

Seeking the Perfect Programmer   45

reflected a growing public awareness, in the wake of the U.S. Civil Rights Act of 1964, that such measures could perpetuate racial or other discrimination. The period covered by this chapter largely predates the civil rights and feminist movements, and few people challenged the discriminatory effects of employment practices in computing, but there is evidence that such practices did have disparate effects on women and men. Perhaps more surprising, employers themselves worried that the “diplomas and tests” that they used to assess potential workers might not accurately represent reality. Employers sought programmers in a variety of ways. They ran ads in major newspapers and put notices in specialized academic newsletters and trade journals. They relied on word-of-mouth recommendations from friends, relatives, classmates, and teachers. They recruited at college campuses, especially for scientific computing jobs, and took referrals from secondary school and college placement offices. In addition, commercial employers often retrained their existing employees for programming work.24 British and American employers faced similar personnel challenges and used similar strategies, reflecting the many links between their computer industries: they exchanged technical and management ideas, a number of U.S. firms (such as IBM and UNIVAC) operated subsidiaries in the UK, and it was not uncommon for programmers to cross the Atlantic to take jobs or attend conferences. As a manager at Mobil UK remarked, “Of one thing I am reasonably sure—the problems will be seen to be no different on the other side of the Atlantic than they are in the U.S.A.”25 Yet there were also significant differences between the two countries’ educational systems that affected employers’ strategies and women’s opportunities, as noted below. One problem that all employers shared was the need to find proxy measures for programming ability. It was simply not practical to observe a job applicant directly as he or she spent months creating a complex piece of software, so employers searched for other indicators that they hoped would correlate with coding skill. Many job ads asked for a college degree, but others left education unspecified. Some employers required applicants to have hands-on computer experience, but in a tight labor market many were willing to hire inexperienced “trainee programmers.” After applicants were invited for an interview, it was common (although not universal) for employers to administer special aptitude tests to screen

46  Chapter 2

and rank them. Job seekers were thus judged on some combination of their education, work experience, test scores, personal impression in interviews, and biographical information. Throughout this period, pervasive sex-typing of jobs meant that employers also drew on gender stereotypes when assessing how well an individual matched the presumed job requirements. The following sections explore how various approaches to recruiting and assessing programmers framed technical skill and how these framings shaped women’s opportunity. College Degrees Many employers sought to hire programmers who had a college degree, preferably in math or science, but in practice this was not easy. In 1950, only 7.7 percent of the U.S. population age twenty-five to twenty-nine had earned a bachelor’s degree, and by 1970, it was still only 16.4 percent.26 A 1966 survey of 483 U.S. employers found that only 35 percent required their entry-level programmers to have college degrees.27 The numbers were even smaller in the UK, where 3.4 percent of the population earned college degrees in 1950 and 8.4 percent in 1970.28 The British employers that placed the most emphasis on college degrees were universities and government labs, where programmers typically had to meet the civil service qualifications for scientific officers. In commercial environments, UK employers were more likely to consider three tiers of educational credentials: O-levels (the ordinary secondary school exam taken at age sixteen), A-levels (the advanced secondary school exam taken at age eighteen), and college degrees. Job applicants with a college degree were often hired directly into senior positions, those with O-levels and no experience could sometimes find entry-level positions, and A-levels occupied a middle ground.29 The rationale for using a college degree as a measure of programming potential was not as logical as it might appear. A math or engineering degree may seem like a natural prerequisite for technical work, but the actual content of those degrees often bore little relation to the requirements of the programming jobs that were advertised. Some employers who asked for a degree did not care what subject it was in or how good the issuing school was. A consultant for several defense and industrial clients in California declared, apparently without irony, “We pay all bachelor degrees about the same whether they come from Podunk U. or MIT.

Seeking the Perfect Programmer   47

They are worth about the same.”30 Many employers regarded the college degree more as an indicator of general intelligence than as a guarantee of ability or knowledge in a particular field. As a representative of McDonnell Automation of St. Louis opined in 1969, “The college degree is evidence of ability to think.”31 A U.S. utility that was hiring business programmers in 1967 noted, “Personnel looks for young college graduates (any major)” because “the accounting personnel supervisor believes that aptitude for this work is closely related to general intelligence and to the ability to learn.”32 Yet given the economic and class barriers to attending college during this period, it could not be assumed that only those with a degree had the ability to think. The gender implications of employers’ preference for applicants with college degrees were mixed. On the one hand, women were less likely to earn college degrees than men, since the expectation that they would become homemakers made them less likely to receive social or financial support to go to college. In the United Kingdom, women made up 23 percent of college students in 1950 and 31 percent in 1970, while women in the United States earned 24 percent of college degrees in 1950 and 43 percent in 1970.33 On the other hand, those women who did earn degrees—especially in math—were often courted by employers. Women faced strong social pressures to study more “feminine” arts and humanities subjects, but nonetheless a substantial percentage of math majors were women. In addition, many employers’ willingness to take any sort of college degree could open unexpected doors for women with nontechnical majors. Women’s experiences also varied by social class, given that college was the domain of a relatively privileged few. It is unclear whether employers of programmers deliberately used college as a class marker, but it is striking to contrast their respect for bachelor’s degrees with their disdain for the more affordable technical, junior, or community colleges. Such schools had quickly expanded their offerings to meet the growing demand for programmers. In 1967, for example, U.S. junior colleges granted 1,300 associates’ degrees in computing, while four-year colleges awarded only 600 bachelor’s degrees.34 As a career advice book noted in 1967, “These schools are often the most practical way for more mature people and those without college degrees to become programmers.”35 A professor at New York City Community College defended such schools as a superior source of programming personnel, arguing that their graduates

48  Chapter 2

did not need training (unlike college graduates, who often had no coding experience) and were less likely to job-hop than the ambitious college grad.36 But technical colleges were looked at askance on both sides of the Atlantic. The Economist reported in 1967 that “Programming schools are sprouting up everywhere, but many are not as good as they should be.”37 A manager from Rolls-Royce was more blunt, calling programming schools “pirates” whose unscrupulous practices and substandard teaching had led to calls for the UK government to regulate them.38 A researcher at the University of Southern California reported in 1968 that programmers and analysts who had completed a college degree did better on aptitude tests than those who had fewer than four years of college. He concluded that a candidate with a two-year degree “usually has less computer-related ability than the fellow who completes 4 years of college” and warned, “The person with less than a bachelor’s degree should be looked at pretty hard.”39 Such comments implied that the educational systems in both countries sorted students (and their instructors) by merit. Firsthand accounts offer a different perspective. For example, Sylvia Wilbur, the daughter of a London dockworker who entered the job market in 1955, described how her options were circumscribed by both class and gender, despite her talent for math: “My family were rather poor—not in desperate poverty, but they needed me to help support the family . . . and that was really why I left school at 17, rather than go to university, though I’d done well at grammar school.” She added, “I was brought up in the expectation, as was common at that time, that—being a girl—I would get married, raise a family; and that was my principle role in life. So I didn’t really think seriously about going to university or having a career.” After ten years of clerical work, she took a job at a local college that involved typing computer programs for students: “And that was how I met computers—and that totally changed my life! . . . I’d been doing this about six weeks, and I found I was starting to correct the students’ programs!”40 For the first time, Wilbur had a sense of other options, and she devoted her energies to completing her truncated education. She studied for the A-level exam in mathematics, began a part-time degree through the Open University (a major distance-learning institution), and earned a bachelor’s in mathematics at the age of thirty-six. Wilbur went on to provide programming support for the first UK node of the Internet, and she eventually became

Seeking the Perfect Programmer   49

a computer science professor. As Justice Burger implied, degrees and test scores could reflect lack of opportunity rather than lack of ability. An even more striking example comes from an unusual program, sponsored by General Electric Company in 1968, to train and place black residents of the Albany-Schenectady area in programming jobs. The program cast a wide net: “No testing was done, a high school diploma was not required, and a police record was no bar.” The students were taught FORTRAN (IBM Mathematical Formula Translating System) and given remedial training in math. Of the thirty-one students who were accepted (about one-third female), eighteen successfully completed the course and were offered jobs. The author noted that contrary to expectations, programming ability did not depend on education: “It is interesting to note the fact that there was not a great deal of correlation between the performance of a student in the class and his performance in or graduation from high school. Of the four students who had not graduated from high school, two were in the top third of the class.”41 Yet such experiments had little effect on the wider computing culture. Accepting black high-school dropouts as potentially talented programmers might have threatened the privileged status of technical skill. Instead, employers clung to the college degree as a promise of merit—although whether that meant specific knowledge, general intelligence, or social standing was often unclear. Experience Most employers wanted programmers with experience—although in this young field, experience could mean as little as six to eighteen months on the job. Even these relatively junior personnel were in short supply, and companies freely raided each other’s staff. The early trade literature is full of complaints about high turnover among programmers and their propensity to leave after they had been trained at their employer’s expense, yet these same writers hoped to hire experienced programmers away from their competitors. As a manager at the National Bank of Detroit admitted, “our deadlines are such that we have no time for training and are looking for experienced people that we can lure from other companies.”42 Like a college degree, “experience” could encompass many meanings of skill. An employer who sought knowledge of specialized techniques might expect that experienced candidates had been trained to use particular machines or programming languages by their previous employer. With

50  Chapter 2

a different framing of skill as tacit knowledge that is gained from handson practice, an employer might hope that veteran workers had learned to recognize typical problems and their optimal solutions. Asking for experience could also be a way to weed out those who lacked the aptitude or interest to stay in the programming profession for long, an attitude that was compatible with a view of skill as an inherent ability or mindset. The premium on experience seems to have worked mostly in women’s favor; it certainly was less of a hurdle than a college degree. After a woman managed to land her first programming job and work for a year or so, she was virtually guaranteed future employment. Programming jobs existed almost anywhere there were large businesses or universities, so an experienced programmer found it relatively easy to find work if she moved to another city to follow her husband’s job—a common career disruptor for women in other fields. Aptitude Tests With experienced workers scarce, aptitude—as measured by standardized tests—became a preferred indicator for many employers, especially those who were seeking business rather than scientific programmers. Programmer aptitude tests were supplied by computer manufacturers (although some employers devised their own) and were widely used in the 1950s and 1960s.43 By far the most popular was the IBM Programmer Aptitude Test (PAT); others included the UNIVAC Programmer Aptitude Battery, the National Cash Register Programmer Aptitude Test, and the SRA/ Burroughs Computer Programmer Aptitude Battery.44 A 1967 handbook titled How to Pass Computer Programmer Aptitude Tests warned readers, “Nearly all business firms and branches of government that hire programmers require a computer programmer aptitude test. You will find it almost impossible to gain entry into the programming profession unless your score on the computer programmer aptitude test compares favorably with scores achieved by successful programmers.”45 Although the author’s advice was self-serving, it may have been accurate. A 1966 survey of U.S. employers found that 68 percent used some kind of aptitude test when hiring, with 85 percent of these choosing the IBM PAT; the total number of programmer aptitude tests administered that year was estimated at 700,000.46 Trade schools also urged prospective students to take a free aptitude test to help them decide whether to study programming. It was possible to enter the field without taking such tests, particularly if

Seeking the Perfect Programmer   51

one had a math or science degree, but they were a widespread screening device that could make or break a job seeker’s chances. Aptitude tests framed programming skill as a combination of mathematical and logical ability. They typically consisted of sets of multiplechoice or fill-in-the-blank questions involving basic algebra and various types of logic problems. The IBM test had sections on “number series, figure analogies, and arithmetical reasoning”; other tests used verbal analogies as well.47 No knowledge of computers, advanced mathematics, or engineering was required to do well on these tests. In fact, W. J. McNamara, cocreator of the IBM programmer aptitude test in 1955, described the PAT as a move away from equating programming skill with advanced mathematical knowledge: “It was commonplace to associate mathematical knowledge with programmer skill. . . . However, a careful analysis of the situation indicated that mathematical knowledge was associated with the application and not with programming ability. . . . [T]here appeared to be one basic requirement for a good programmer; that was analytical ability or logical reasoning ability.”48 The PAT was supposed to target this more general “reasoning ability.” Also measured implicitly by the test— and perhaps as important as any of the explicit subject areas—were carefulness, ability to follow instructions, and attention to detail. Testing aptitude is a fundamentally different approach from requiring a certain level of education or experience. It implies that some people have innate, measurable skills and that such people can be trained to perform well at programming regardless of their background. A 1969 ad for the SCP Computer Training Center in London played on this belief, luring prospective students with the promise that “Many people, unknown to themselves, have latent ability.”49 Aptitude tests can also be seen as an attempt to measure directly the same qualities that were assumed to come with a college degree, such as logic, general intelligence, and discipline. Perhaps because of this, data from 1966 show that employers who used aptitude tests tended to have lower educational requirements: 32 percent accepted a high school degree as the minimum education for a programmer trainee, compared to only 16 percent of employers who did not use the tests.50 The tests provided employers the reassurance of a standardized, quantitative measure to guide hiring decisions and allowed them to consider a wider applicant pool while still being selective. But did aptitude tests really identify the qualities that were needed for success in computer programming? Contemporary assessments suggest

52  Chapter 2

that they were far from accurate predictors. The tests were calibrated by giving them to students in IBM training classes, and the results of the test were found to correlate with “success in training”; there was no guarantee that this would translate into success on the job.51 The 1966 study cited above noted, “It is readily apparent that very few organizations are attempting validation studies to determine whether the psychological tests used are selecting the type of people that are successful within their organization.”52 Studies that did attempt to correlate aptitude test results with actual programming performance often failed to find a connection.53 A 1969 article in the trade journal Business Automation quoted criticisms of the test by E. W. Jacobi, personnel director at Illinois Bell Telephone: “‘The aptitude test indicates aptitude for programming, but it does not show that the individual can or has a desire to do programming,’ Jacobi says. ‘We used to lose about 30 percent of the programmers we hired. They simply couldn’t make it. We realized there was something inherent in a programmer.”54 Jacobi did not specify what that something might be, but he still accepted the underlying belief in “inherent” programming talent, even though he felt that the test was a poor measure of it. That fact that such tests were widely used even though many regarded them as highly flawed underscores the difficulty that employers had in pinning down the qualities of the ideal programmer. Aptitude testing could work to women’s advantage by providing a seemingly objective measure of their technical ability, thus countering gender stereotypes and the effects of previous constraints on their education. A woman who had never had the chance to earn a college degree—or who had been steered into a nontechnical major—could walk into a job interview, take a test, and instantly acquire credibility as a future programmer. An illustrative example is Ann Hardy, who wanted to study chemistry in college but reluctantly chose physical education instead after the male chair of the chemistry department refused to accept any female majors. When she applied for a programming job at IBM in 1956, the personnel manager initially balked at Hardy’s phys. ed. degree, but Hardy persisted in asking to take the IBM aptitude test. She got an excellent score and was offered a job, the beginning of a long and successful career.55 In a similar vein, Kathy Humphry recalled graduating from the University of Saint Andrews in 1966 with “a really wussy, ‘female’ degree: psychology and economics,” although she had always been

Seeking the Perfect Programmer   53

good at mathematics. The school’s careers officer surprised Humphry by recommending programming jobs, noting that employers would give her aptitude tests rather than judging solely by her degree subject: “So with this entirely dotty degree I went for these aptitude tests, and did fine, and got accepted by all these companies.”56 Aptitude tests were also used by companies to recruit internally, allowing some women in clerical or operator positions to move up into programming.57 Of all the methods for assessing potential programmers, aptitude testing may have offered the lowest barriers to women. The tests offered real opportunities, but these must be seen against a backdrop of pervasive skepticism about women’s technical ability. Soon after the 1971 Griggs decision quoted earlier, William H. Enneis of the U.S. Equal Employment Opportunity Commission chastised computer personnel managers for ignoring their own aptitude test results in favor of sex-typing: “For example, in one company all the keypunch operators were women and all the programmers and computer operating personnel were men! This was so even though the mean scores for the women were higher than those for the men on each test being used to assess aptitude for computer work.”58 Good test scores were no guarantee of fair treatment. Occupational Metaphors for Programming Skill This tour through the various proxy measures of programming ability has revealed both the difficulty of assessing technical skill in a new field and the many ways in which ostensibly objective standards are saturated with cultural values. Another way of uncovering the social basis of skill assessments is to look at how employers drew connections between programming and more familiar occupations. I refer to such associations as metaphors to highlight how each comparison created a selective interpretation of the programming task based on the assumptions and values of another field. Depending on the comparison chosen, programming might appear high or low status, abstract or concrete, creative or routine. The three most common metaphors were mathematics, engineering, and business. Mathematics suggested an abstract view of programming as simply the last, mechanical step of an essentially mathematical process of problem solving. Engineering implied a more concrete view of computers as physical instruments and carried the expectation that workers might

54  Chapter 2

need to integrate hardware and software design. The business metaphor associated computers with older and less exotic office machines such as typewriters and punched-card tabulators; it deemphasized science and placed value on knowledge of application areas and on management potential. The sections that follow discuss the implications of these metaphors, their sometimes tenuous relationship with the actual demands of programming, and their effects on gendered structures of opportunity. The division of labor by sex in postwar America and Britain meant that metaphors used for computer programming could have a significant effect on women’s participation. For example, women made up a tiny percentage of engineers throughout this period but were relatively well represented in mathematics. In business, women dominated clerical work, including operating office machines, and were well represented in some mathematically oriented specialties such as accounting but were scarce at the management level. Thus the characterization of computers as an engineering tool, a mathematical device, or a business machine mattered greatly in constructing females as possessing the skills necessary for programming. Mathematics Perhaps the most commonly sought quality in programmers was mathematical ability. Many job ads asked for math degrees or skills, employers targeted college math departments for recruitment, and until the mid1950s programmers were often given the job title of mathematician. A 1964 article in the academically oriented journal Communications of the ACM proposed that the professional programmer should have “A minimum of two years of applied mathematics . . . an especially quick recall of trigonometric and geometric relations, three semesters of engineering calculus with emphasis on techniques, a course in numerical analysis and one or two semesters of linear algebra.”59 At first sight, this emphasis on mathematics seems justified. The earliest applications of digital computers, which were military or scientific, did require some mastery of mathematics. Lucy Slater, for example, earned a Ph.D. in mathematics in 1951 and went on to program the EDSAC computer at Cambridge University to solve hypergeometric equations, driven by her desire to accurately model the behavior of a hydrogen bomb “before somebody blew the world up.” 60 In addition to the demands

Seeking the Perfect Programmer   55

of specific applications, before the mid-1950s scientific programmers had to perform mathematical tasks that we now expect computers to do for us, such as scaling floating-point numbers to fit into the amount of memory allocated for them (see chapter 3). Yet “mathematics” was also a slippery concept because even in science-heavy areas such as aerospace, the skill that was actually needed was applied mathematics, which was rarely specified in job ads.61 Most college math departments taught higher-status pure mathematics with little if any attention to applied topics.62 The National Research Council noted with concern in 1956 that most programmers acquired the needed skills in applied math only after being hired, usually in classes offered by computer manufacturers.63 For business programming, the value of a mathematics degree was even more questionable. A 1971 survey of graduates of one of the early computer science degree programs at Penn State University reported that those who were employed as programmers found that their theoretical math courses were the least helpful part of their education.64 Given the rather loose correlation between a mathematical education and the actual demands of programming work, mathematics may have served more as a metaphor for other intellectual abilities. Consider a 1954 ad seeking a “Junior Programmer-Coder” for “business-type problems”: “For this opening we are looking for an outstanding recent college graduate with major in physical, biological sciences or mathematics—a logical young man, patient with small, complicated details.”65 Even though this business programmer was unlikely to face any tasks involving physics, biology, or advanced math, training in these sciences was assumed to either preselect or cultivate traits of logic, patience, and attention to detail that the employer deemed important for programming. The association of programming with math proved helpful to many women. Women were more likely to major in math than any other science, earning 27 percent of U.S. math B.A.s in 1960, 33 percent in 1966, and 37 percent in 1970.66 Women were also more likely than men to have entered programming with a math background. A 1964 survey of U.S. programmers found that slightly more than half of the men had degrees in math, compared to 60 percent of the women.67 Employers such as IBM avidly recruited female math majors into computing, a field that the women might not otherwise have considered. For example, Carol Shanesy, who was completing her master of science degree in math at

56  Chapter 2

Northwestern University in 1959, described how one of her professors called his graduate students together and sheepishly admitted that he had allowed an IBM recruiter to come to campus but had forgotten to arrange any interviews. “Go up there and act like you want a job!” the professor urged them. Shanesy obligingly agreed to meet with the recruiter, who seemed determined to hire her: “At some point in this interview, I’m getting increasingly uncomfortable because he wants me to come out to New York . . . and I’m [thinking], ‘This whole thing is a charade!’ . . . . I made it very clear that I probably wouldn’t take the job.” The recruiter eventually persuaded Shanesy to fly to New York for an interview, and she ended up taking the job, the start of a lifelong career at IBM.68 Yet although mathematics was relatively welcoming to women, this very fact meant that too close an association with mathematical work could threaten the professional status of programmers. As noted in chapter 1, in the 1940s and 1950s, thousands of female mathematicians were employed in subordinate jobs doing repetitive calculations of the type that computers were invented to automate.69 As programmer Elsie Shutt recalled, “The desk calculating thing was ‘women’s work’: you needed to be careful and patient, and not very creative; you had to be willing to just sit and crunch the machine.”70 Because of the stigma attached to “women’s work” in mathematics, programmers and those recruiting them struggled to distance themselves from any notion of the computer as a glorified adding machine. Mary Kircher, who began programming at Los Alamos National Laboratory in 1952, drew a distinction between the sophisticated logic that was required to design a program and the routine desk-calculating work that she felt was invoked by the term coding: “In a way we were encoding arithmetic, and in a way we were doing a program that the machine could follow—because that was the big difference with the digital electronic computers: they could follow a program; they could accept instructions, as well as accepting numbers like an adding machine does.”71 A 1956 brochure by the U.S. Department of Labor touting employment opportunities for female mathematicians admitted, “Until recently, many women with the B.A., or even the M.A., in mathematics did routine work only” but went on to insist that “programming is not routine.”72 This defensive tone is echoed in a 1960 ad by Sylvania Electronic Systems that assured mathematicians, “This is not a routine job. .  .  . It is not ‘programming’ as it is commonly known.”73 Mathematical training could be

Seeking the Perfect Programmer   57

a route into satisfying programming jobs for women but only—paradoxically—if those jobs were not too closely associated with “women’s work.” Engineering Computers were large, complex, electronic machines, so it was not surprising that many employers saw programming as a form of engineering. This was especially true in industries such as aerospace and electronics. North American Aviation listed computer programmers among the types of “forward-looking engineers” that it sought for work on missile projects, Lockheed Electronics advertised for “Systems Engineers” in areas including programming techniques and data processing, and Curtiss Wright of New Jersey wanted to staff its Polaris missile project with “Digital Computer Engineers,” including programmers.74 Computer manufacturers liked to present their machines as generalpurpose information processors, but industrial users often had a different interpretation of the computer, seeing it as a piece of special-purpose electronics equipment that was akin to familiar tools such as radar, navigational aids, or scientific instruments. Such employers often expected programmers to have expertise with both hardware and software. For example, a Westinghouse subsidiary’s 1954 ad mixed hardware components with software techniques when it asked for “Computer Specialists” with experience in “Shift Registers, Gates, Coding Methods, and Magnetic Cores.”75 Among various positions for “Engineers & Physicists” in a 1961 ad, the AC Spark Plug Division of General Motors sought programmers “to program and to aid in the design and development of advanced guidance digital computers.”76 Another indicator that employers considered programming to be subordinate to the main business of engineering was their lumping together of analog and digital programming, which required very different sets of skills.77 In a 1956 ad for “computer specialists,” “computer programmers,” and “computer application engineers,” North American Aviation promised, “you will use the finest digital and analog computers and other advanced research and test facilities at Autonetics.”78 A 1958 Lockheed ad even nonsensically referred to “Analog Digital Computer Programming and Operations.”79 By ignoring the distinction between analog and digital computing, these ads suggested that the engineering context was more important than any specific programming skills. Engineers who assumed that building a computer was where

58  Chapter 2

most of the skill lay might see programming as a generic task that any competent engineer could pick up. Yet as with mathematics, the assumption that programming was a subset of engineering was not as logical as it might appear. Engineering knowledge was required to build a computer, but it is much less evident that it was needed to program one. Identifying programming with engineering was arguably a status move. Historian David Alan Grier has noted that the term programmer was deliberately chosen in the late 1940s to evoke the glamorous new field of electronics engineering and to distance computing from the low-status, feminized job of hand calculating.80 Joyce Currie Little echoed this logic when she explained why she was called a “testing engineer” when she joined Convair in 1957, even though her background was in math and biology and her job was programming. Little described this title as an attempt to give programmers commensurate standing with their engineer coworkers: “You were an engineer, which is more status than a lot of early programmers got when people didn’t know what to call them. . . . In the engineering world, it’s important to be called an engineer.”81 The engineering label may have made programming less welcoming to women. Engineering was (and remains) a highly gendered occupation in the United States and United Kingdom.82 Women were only 1.2 percent of engineers employed in the United States 1950 and remained under 2 percent for the next two decades.83 A female science correspondent to the London Daily Telegraph reported in 1968 that women engineers “are very much in the minority and still objects of curiosity,” referring to “the popular image that it is necessary [for a woman] to wear lisle stockings and brogues and have a roar like a sergeant major” to fit in as an engineer.84 Such images were not likely to draw women into programming jobs that were identified with engineering. Business By the mid-1960s, the majority of programming jobs were for commercial rather than scientific applications. Business managers tended to define skill differently from their scientific counterparts, valuing knowledge of the application area and the corporate culture more than knowledge of computers per se. Some commercial managers felt that a scientific orientation

Seeking the Perfect Programmer   59

was actually a liability for programmers, fearing that employees who were too narrowly technical would lack communication skills or business sense. For example, a paper on “Selection and Training of Programmers: A Business User’s Approach” presented at a 1959 British Computer Society symposium warned that scientifically oriented personnel might waste time on clever coding tricks. The author advised, “Choose plodders who will attend to detail, rather than those who may be very bright but be inclined to spend too long searching for short cuts.”85 Two studies that were presented at the 1964 ACM conference on Computer Personnel Research critiqued programmer aptitude tests, which were widely used in hiring business programmers, because programmers who scored high on aptitude tests were rated favorably by scientific supervisors but much less so by business supervisors. This implied that some aptitudes valued by the scientific community were actually viewed as dysfunctional in a commercial environment.86 A manager at the RAND Corporation agreed that technical talent had a negative correlation with managerial ability, noting that “psychological studies of mathematicians as a class have almost universally found that, as a group, they are a highly introverted lot. . . . Those individuals who excel on programmer selection tests seem to have very little leadership potential.”87 Reflecting these different priorities and values, business-oriented ads emphasized that programmers should have management and customer-interaction skills—traits that were completely absent from ads that focused on math or engineering. For example, Mobil Data Services Limited (UK) listed “accounting principles,” “general business practises,” and “communications skills” as three of the four areas that entry-level programmers should know.88 Recruiters of commercial programmers were also less likely to ask for college degrees and more likely to consider graduates of trade schools.89 These schools varied greatly in their ambitions and quality. As noted earlier, some were exposed as mere scams, but others offered a sound if limited introduction to programming fundamentals. A typical 1960 ad for the Sawyer Schools in Los Angeles promised “a new career opportunity after only a few weeks: IBM computer programming, supervisor preparation, tabulating & wiring.”90 As this ad illustrates, trade schools often mixed training on computers with established business machines such as tabulators, thus reinforcing the image of programming as a subset of business practice rather than science or engineering.

60  Chapter 2

An application-oriented view of computing made commercial employers more likely than scientific installations to recruit programmers from their existing staffs. As a 1966 guidebook on business data processing observed, “It is usually easier to train someone who is already familiar with the company’s systems to be a programmer than it is to teach the company’s systems to a programmer.”91 A survey of UK employers reported in 1968 that 20 percent of junior programmers had been promoted from within the company, while a 1969 case study of a U.S. financial company found that twenty-eight of its thirty-one programmers and analysts had worked at other jobs in the company before being transferred to the data processing department.92 What were the gender implications of the business view of computing? Employers’ emphasis on communication skills (often seen as a feminine trait), their tendency to recruit programmers from within the firm or from trade schools, and their reliance on aptitude tests opened up opportunities for women who lacked a college degree or a science or engineering background. However, programming jobs varied widely in pay, status, and promotion prospects depending on which aspect of business they were associated with. Clerical work, accounting, sales, and management each had complex gender connotations. Characterizing programming as clerical work made it more accessible to women, who disproportionately occupied these lower rungs of the business ladder. Programming offered upward mobility to some women who operated office machines such as tabulators and Comptometers, since employers often retrained some of these operators as programmers when a new computer system was installed.93 Those clerical workers with no office machine experience could occasionally move into programming by passing an aptitude test. But casting programming as a glorified form of clerical work also lowered its status, given the general devaluing of women’s work as dead-end and routine. For this reason, programmers themselves strongly rejected the clerical label. Accounting was one of the major business applications of computers, and when companies began to automate their data processing in the 1950s, it was not uncommon for accounting personnel to transfer to new jobs as programmers. The experience of Betty Cooper illustrates how accounting skill—and a willingness to try something new—could substitute for a college degree in opening the door to programming work. Cooper

Seeking the Perfect Programmer   61

started working in 1949 as a cost accounting clerk at J. Lyons and Co. Her family could not to afford to send her to university, so to progress in her career she took a correspondence course in accountancy and passed a professional exam in 1953. Lyons rewarded her initiative by inviting her to take an aptitude test and introductory course for the new LEO computer in 1954. She recalled that her fellow accountants “pooh-poohed the idea of LEO” since business automation was virtually unheard of at that time: “I was very skeptical. And I suppose because I was skeptical, I didn’t worry about how I did—and so I did quite well!”94 Deciding that the computer had some potential after all, Cooper joined the programming team in 1955. When English Electric joined forces with Lyons in 1963 to turn the LEO into a commercial product, they drew on the familiar image of women as accountants to sell customers on the idea of women as programmers. In a remarkable 1963 ad promoting its software services, English Electric simultaneously positioned female programmers both as eye candy for male managers and as competent, no-nonsense technical experts. Under a photo of a glamorous woman suggestively holding a pen to her mouth, the headline asked, “Why pick a woman to pep up your accounting department?” and then supplied a leering answer: “Some of English Electric Leo’s best computer programmers are as female as anything” (figure 2.1). Yet despite the sexual innuendo of this photo and headline, the main text of the ad describes female programmers as “competent” at giving “orders” to the machine and possessing a “logical flair” for writing programs. The intent seems to have been to present programmers—like female accountants before them—as both technically adept and unthreatening to the masculine corporate order. Things became more problematic for women when programming was viewed as part of sales and management, both of which were male strongholds within the corporation.95 Before the rise of the software industry in the 1970s, computer manufacturers bundled programming services along with the sale or rental of their machines, and this “free” software could be an important selling point. Programmers on the sales team helped generate new business by interacting with customers and making sure that their software needs were met.96 For example, National Cash Register, one of the early computer manufacturers, specified in a 1960 ad that they needed a senior programmer who “Works with Data Processing

62  Chapter 2

Figure 2.1 Ad for English Electric–LEO Computers Limited: “Why pick a woman to pep up your accounting department?,” 1962.

Seeking the Perfect Programmer   63

customers; recommends and develops new applications.”97 RCA, another early player in the computer industry, advertised for “EDP Programmers and Methods Analysts” with “experience in EDP sales or technical services” to “work closely with both customer and sales personnel in the development of specific applications, related procedures, and programs.”98 Sales jobs were commonly used to groom junior staff for management positions—but only if they were male. Women were steered into lowervisibility, postsales positions in customer support, where their interpersonal skills were valued but not necessarily rewarded. IBM was a major employer of female support personnel who were formally titled “systems service representatives” but were widely and tellingly known as “systems service girls.” ENIAC programmer Jean Jennings recalled how, when she entered the job market in 1945, a college friend warned her away from this feminine ghetto: “One of the girls that was hired wrote back that it was horrible: that they expect you to dress like mad, but they don’t pay enough money . . . and she said you work like a dog! So it wasn’t that appealing.”99 In the decades before civil rights laws made it illegal, companies were open about the double standard whereby technical skill could lead to a management career for men but not for women. Ann Hardy, the former phys. ed. major hired by IBM in 1956, recalled that after the new recruits had gone through the company’s six-week introductory training, “They took the top three people and offered them positions in sales, because that’s where you can get the most money and where you can go up the corporate ladder. I was one of the top three, but they took me aside and said, ‘Women can’t be in sales, so you can be a systems service girl or you can go into programming.’”100 As it turned out, IBM’s presumption that women lacked management ability was wrong in Hardy’s case. After spending several years developing supercomputer software at IBM Research, Hardy went on to become a vice president of Tymshare, one of the earliest computer network service providers, and later founded her own company, Agorics. But the contemporary bias against women in management was ubiquitous, and it is not surprising that IBM—although fairly progressive in hiring women for research positions—shared it.101 What is more intriguing is that by Hardy’s account, IBM recruiters routinely equated programming aptitude with potential success at sales and management. It was only when an outstanding female candidate appeared that the recruiters were forced to articulate their tacit belief that there was another essential managerial trait—masculinity.

64  Chapter 2

Marie Hicks has described how the British government made the connection between programming, management potential, and masculinity even more explicit in the early 1960s, when it initiated a policy of recruiting programmers from the 90 percent male “executive class” of the civil service.102 The role of masculinity as a norm or ideal for managers became even more evident when employers tried to judge whether their programmers had qualities such as “character,” “personality,” “dedication,” or “leadership potential.” These personal factors were at least as hard to define and measure as technical skill, and employers’ attempts to identify them often contained hidden gender bias. For example, a manager at National Cash Register defined “Job Commitment and Effort” to include “Putting in long hours and extra time” and “Working on own time to acquire knowledge”—criteria that would have been difficult to meet for a woman with family responsibilities outside of work.103 A consultant for a U.S. financial company equated “motivation” with “aggressiveness” when rating the company’s programmers. Not surprisingly, he placed a smaller percentage of women than men in the “most motivated” category, even though the women had scored equally high on a separate measure of “aspiration.”104 A 1966 textbook that described the qualities needed by data processing managers stressed experience, hard work, and knowledge of the business but also an air of authority that was culturally associated with males: “Sufficient poise and stature to be able to gain the time, attention, and cooperation of members of the organization’s management group.”105 Here, the employee’s merit is judged by other people’s willingness to cooperate, a form of circular reasoning that left existing social biases unchallenged while blaming the victims for their alleged lack of “poise and stature.” As has been shown, the meaning of programming as a business skill depended crucially on gender. Combined with masculinity, programming aptitude could lead to a well-rounded career in management. For women in administrative positions, it could sometimes be a ladder to advance from dead-end jobs, but they were likely to hit a glass ceiling that blocked their advancement into the higher ranks. Programming as a Feminine Skill: Stereotypes and Counternarratives The dominant view of technology a masculine field structured the entire process of job recruitment. For example, until the advent of

Seeking the Perfect Programmer   65

antidiscrimination laws in the 1960s, U.S. newspapers typically listed job advertisements under separate headings for “Help Wanted—Male” or “Help Wanted—Female.” UK newspapers distinguished between “Appointments” and “Women’s Appointments” until the mid-1970s. Technical job categories such as engineering appeared only in the men’s sections, so that even if an individual employer wanted to run a gender-neutral ad, it would have been difficult. Jean Sammet, who became a well-known expert on programming languages, recalled how she had to venture into masculine territory in her early job searches: “In 1958, first of all, there were separate men’s and women’s ads . . . and I assure you that under ‘Women’s’ there was no such thing as engineer, mathematician, programmer, or anything like it. It was clerks, teachers, housekeepers, whatever. So I learned to look under the ‘Men’s Help Wanted.’ . . . I had to look under ‘engineering’ and then look at the job description to see whether or not there was something that I thought I could do.”106 But the widespread sex-typing of jobs was partly countered by the efforts of some employers, as well as women in the field, to create alternative images of programming as a feminine skill. Some government and private employers actively targeted women for computing jobs in hopes that they would be more loyal or less costly than their male peers (figure 2.2). The U.S. Labor Department reported in 1956 that “It is a fact that many industrial laboratories employ only women for their computing groups; other employ a high percentage of women.”107 IBM produced an elaborate recruitment brochure for college-educated women in 1957, entitled “My Fair Ladies” after the recent Broadway hit. It pictured several women (real employees, not models) who worked for IBM as programmers or researchers and promised, “If you are attracted by the challenge of a highly important position that will make full use of your talents and aptitudes . . . you’ll like IBM.”108 A UK journalist’s somewhat rosy assessment in 1968 claimed that “Over the whole of the industrial field the people who offer a really warm welcome to qualified women are the computer firms. In programming and the next step, systems analysis . . . , women are every bit as welcome as men.”109 To help make women feel welcome, female programmers and those urging their employment used metaphors that associated programming aptitude with more “feminine” pursuits such as knitting, music, and cooking, thus casting women’s participation in computing as natural and

66  Chapter 2

Figure 2.2 Image of a female programmer from an IBM recruiting brochure, “My Fair Ladies,” 1957.

desirable. Some of these appeals to feminine ingenuity may have been attempts by employers to tap women’s labor potential without seriously challenging the dominant gender system that constructed technical competence as masculine. Such rhetoric is reminiscent of the World War II billboards that recruited women into temporary factory jobs. But other uses of metaphor constituted a more radical challenge to the idea that programming required masculine skills. Women’s own characterizations of programming created counternarratives that normalized and celebrated their own experiences as programmers, while simultaneously revaluing traditional feminine skills as components of technical ability. Feminine Stereotypes in Recruitment Stereotypes about women’s natural abilities (such as cooking and sewing) were sometimes deployed to persuade women or employers that programming could be a suitably feminine pursuit. For example, an executive

Seeking the Perfect Programmer   67

from the UK staffing firm Applied Systems and Personnel claimed in 1968 that “girls sometimes make better programmers than boys” because “an intelligent girl who has the patience to do embroidery has just the right mentality to do the job.”110 Betty Campbell recalled how MIT’s new Computing Laboratory, where she began programming in the 1940s, also used needlework as a reference point for skill: “Nobody, of course, was trained in computers, so they were looking to hire people with certain characteristics, like if you played chess. Well, I didn’t play chess. And then they said, ‘. . . and people who knit,’ and I thought, ‘I’ve made it: I knit!’”111 The 1968 guidebook Your Career in Computers suggested that readers who enjoyed “cooking from a cookbook” might have a natural aptitude for programming.112 Grace Murray Hopper offered her own domestic metaphors in a 1980 interview: “I think that it’s always been true that women were more willing to finish the job. They’ll stay with it; tie up all the loose ends. If they make a dress, they put the snappers and button holes in. . . . Then I always said that the concept of getting the data all together so you could operate on it was the same thing as getting a dinner ready.”113 As these comments illustrate, some experts asserted that women were even more suited to programming work than men. They attributed this to supposedly feminine personality traits or skills, such as patience and attention to detail. Herbert D. Benington, who had overseen software development for the SAGE (Semi-Automatic Ground Environment) air defense system at Systems Development Corporation in the 1950s, recalled, “Women turned out to be very good for the administrative programs. One reason is that these people tend to be fastidious—they worry how all the details fit together while still keeping the big picture in mind. I don’t want to sound sexist, but one of our strongest groups had 80 percent women in it; they were doing the right kind of thing.”114 The 1966 textbook quoted earlier that described data-processing managers as needing “stature” nevertheless found women suitable for lower-level programming jobs: “Women have been successful in making significant inroads into this occupation. In fact, they seem especially adapted to this type of work because their temperament is better suited to perseverance and patience.”115 An article that same year in the London Guardian likewise asserted that programming required “patience and tenacity, and a common-sense sort of logic. Much of the work is tedious, requiring great attention to detail, and this is where women usually score.”116 In a 1963 Datamation

68  Chapter 2

editorial on “The Woman Programmer,” news editor Valerie Rockmael noted (with a touch of sarcasm) the prevalence of such backhanded praise for women’s supposed skill at mundane tasks: “Intuitive generalizations made by some personnel managers are that women have greater patience than men and are better at details, two prerequisites for the allegedly successful programmer. On the subject of whether women possess logical, analytical minds the controversy becomes more intense.”117 Rockmael’s commentary reveals a double ambiguity: (male) managers were unsure which intellectual capacities might be linked to gender, but they were also uncertain about which skills were actually required for programming. There was a temptation to reason backward: if women did well at programming, it must be because programming utilized stereotypically feminine skills such as patience and meticulousness. Such characterizations may have made it easier for women to contemplate or be hired for programming jobs—but were they promoting gender equality or merely demoting programming to the kind of routine clerical work to which women had traditionally been consigned? Unlike some occupations (such as clerical work itself) that became female-dominated and lost status, in programming women remained a small minority of the postwar workforce in the United States and United Kingdom.118 There is little evidence that anyone wanted or expected programming to become “feminized” in the sense that men would lose interest in these jobs and employers would focus most of their hiring efforts on women as a cheaper and more docile workforce. In the programming field, the conceptual categories of skilled work and women’s work were not mutually exclusive but rather existed in ambiguous tension. Domestic metaphors took advantage of this ambiguity to invite, explain, or justify women’s participation. Counternarratives of Feminine Skill Other types of metaphors went further in depicting programming as both highly skilled and a natural feminine pursuit. Some commentators linked programming skill to facility with language and the arts, areas in which women were traditionally expected to excel. A 1964 survey of “Vocational Interests of Computer Programmers” noted “the prevalent belief in a relationship between programming and musical activity” and found modest statistical support for it.119 The U.S. Department of Labor’s 1956 pamphlet on Employment Opportunities for Women Mathematicians

Seeking the Perfect Programmer   69

and Statisticians quoted staff at the National Bureau of Standards: “Success in the programming and coding field requires .  .  . a special aptitude—like that for music. Seeking a pre-professional indication of this talent, it was noted that most of the Bureau programmers and coders like puzzles.”120 Margaret Marrs recalled that when she interviewed for a programming job at the British computer manufacturer Ferranti in 1951, the recruiter assured her, “I’m told that if you like doing crosswords, you’ll like this.”121 Such analogies positioned women as potential programmers and also evoked an alternative vision of programming itself—as a creative, artistic, literate pursuit and quite different from either engineering or tedious clerical work. Occasionally, this counternarrative erupted into an explicit critique of the prevailing standards for programming skill. For example, John Salerno of the U.S. Army Signal Research and Development Laboratory argued in 1959 that employers should seek a greater diversity of talents among programmers: “It is undesirable to overemphasize the sciences and neglect the humanities and letters. Yet too often systems analysts and programmers are regarded as recruitable exclusively from mathematicians, engineers, and the like. This is myopic. The computer world does and will require many skills among its people.”122 Ida Hoos made a similar argument when she described a successful programming team at a government installation that included a musician and several women from clerical and office-machine jobs: “an ex-farmer, a cellist, a former tabulating machine operator, an ex–key-punch operator, a girl from the secretarial ranks, and a mathematics major with a Master’s degree.” She added pointedly: “The last mentioned was considered the least competent of the group!”123 Your Career in Computers assured readers that not only was a technical background optional but that often “the creative people—the writers, poets, and musicians—are far better suited to solve the problems on which the computer will be used.”124 In this alternative view of computing, the arts and humanities would equip programmers to work with human users and real-world applications, not just interface with the machine. What may have begun simply as an effort to solve the programmer shortage by broadening recruitment led some practitioners to reimagine programming itself as a holistic problem-solving skill and to recast the liberal arts as relevant preparation for computer work.

70  Chapter 2

Another type of metaphor, used mainly by female programmers themselves, drew on women’s expected social roles as mother or teacher. These metaphors functioned as counternarratives in two ways. First, they redefined programming as something that benefited from interpersonal skills such as empathy, nurturing, and communication. Second, they implied that parenting and teaching were themselves challenging domains where aptitude and experience counted, rather than simply tasks that women did by instinct or rote. A striking example of the teaching analogy was provided by Ida Rhodes, who began her career in 1940 supervising hand computers and later played an important role overseeing computer development and procurement for the U.S. National Bureau of Standards. In a 1973 interview, Rhodes equated teaching skill with programming skill: “I had already had the great training of teaching how to do very complicated mathematics to people who knew no mathematics at all. So the machine was really nothing but the [same] sort of [pupil.] . . . For this reason—and I say it unblushingly—I am the very best coder in the world.”125 Here, the largely feminized profession of teaching is presented as the ideal background for a top-flight programmer. Grace Murray Hopper made colorful use of parenting metaphors, even though she had never had children herself. Evidently the contemporary belief that motherhood was a woman’s main function made it easy for her to adopt a maternal persona. In a 1944 memo describing a mathematical calculation on the Harvard Mark I for which she had been the lead programmer, she listed the various team members’ contributions and concluded with a flourish: “Computed, designed, coded, babied, nursed, pleaded with and mothered by—Lt. (j.g.) Grace Murray Hopper, USNR.”126 Clearly proud of her accomplishment, Hopper invoked mothering as a metaphor for dedicated effort, not unskilled drudgery. Several years later, in a marketing memo for Remington Rand, Hopper urged that the company include some software with every computer as a “layette” for the newly delivered machine.127 The implications of this metaphor are provocative: if the computer is a newborn baby, then women would seem best qualified to work with it. But Hopper’s boss at Harvard, Howard Aiken, never grasped this notion, describing Hopper in 1973 with what he apparently thought was the highest praise: “Grace was a good man.”128

Seeking the Perfect Programmer   71

Conclusion Even when gender was not an explicit part of the conversation, ideas about programming skill intersected with gendered structures of opportunity and gendered expectations and norms for employee behavior. “Programming skill” was a malleable concept whose interpretation affected women’s chances in the job market—or, indeed, their inclination to try for programming jobs in the first place. But although women faced systematic barriers to claiming technical skill, a substantial number made a place for themselves in computing by foregrounding their mathematical training, daring to explore nontraditional employment paths, and resisting sextyping—or turning it to their advantage through alternative metaphors. Gendered assumptions about the nature of technical expertise may also have contributed to the widely lamented failure to reliably identify which workers would make good programmers. The dominant interpretations of skill privileged a few aspects of a complex and varied job. The high-status skills of math and engineering seem to have been overemphasized compared to their utility in programming, and skills that proved important in actual programming practice—such as teamwork, courtesy, communication, and passion—were not emphasized in the usual hiring criteria.129 Such yardsticks needlessly disadvantaged women, depriving job seekers of opportunities and the industry of much-needed workers. Employers also bemoaned the lack of senior personnel with broad technical and managerial expertise, again suggesting that their criteria for skill had been focused too narrowly. Another detrimental effect of undervaluing people skills was that in some cases, programmers were rewarded more for raw code production than for meeting the user’s needs. Marge Devaney, a programmer at Los Alamos National Laboratory in the 1950s, recalled sex differences in how programmers judged their performance. Asked if she had ever experienced gender bias on the job, she replied that discrimination was difficult to prove, adding, “With things like computing, it’s very hard to judge who’s doing the best. Is it better to produce a program quickly and have it full of bugs that the users keep hitting, and so it doesn’t work? Or is it better to produce it more slowly and have it so it works? . . . I do know some of the men believed in the first way: ‘Throw it together and let the user debug it!’”130 This critique is echoed by women today who find their

72  Chapter 2

male peers rewarded for averting disasters through heroic last-minute efforts, while women’s efforts at preventing such problems through careful work and communication with users go unrecognized. As a female software engineer complained in 2007, “Why don’t we just build the system right in the first place? Women are much better at preventive medicine. A Superman mentality is not necessarily productive; it’s just an easy fit for the men in the sector.”131 The history of early attempts to identify skilled programmers is relevant to current policy debates because it challenges the notion that standards and equity are mutually exclusive. The realization that our criteria for skill may be arbitrary and biased toward masculine behaviors undermines the presumption that women simply lack interest or ability in computing. It suggests instead that reimagining job qualifications for computer professionals could be one way to recruit and retain a diversity of talent and find a better balance between preventive medicine and superhuman rescues in programming practice.

3 Software Crisis or Identity Crisis? Gender, Labor, and Programming Methods

To judge from some of their professional literature, software developers have lived in a state of perpetual crisis from the 1950s to today. Experts have complained that there are drastic shortages of skilled programmers, that software management is disorganized and workers undisciplined, and that large software projects are too often late, over budget, and full of bugs. But other practitioners, as well as some historians of computing, have treated this sense of alarm with skepticism. As an article in the UK Computer Journal scoffed in 1998, “Ever since the coining of the term ‘software engineering’, software engineering has constituted itself as being in crisis. . . . Some incredulity must be exercised about this notion of permanent crisis.”1 This chapter examines efforts to improve programming methods that were made from the early 1950s to the early 1970s, uncovering some of the social agendas that lurked beneath the technical issues. In the 1950s, the term automatic programming described a set of new tools—notably compilers and high-level programming languages—aimed at making software production easier and more efficient. Despite some real gains from these methods, the demand for programmers continued to outpace supply, and the failure of some high-profile software projects in the early 1960s led to the first declarations of a software crisis. One response was a movement to create a new discipline called software engineering, which encompassed a range of approaches, including mathematics-based programming methods, top-down organization of programs, and software management techniques. Although aspects of these events have been described in other histories of computing, this chapter pays particular attention to the multiple, contested meanings of such terms as automation, crisis, and engineering to show how the ongoing debate over programming methods was also a struggle

74  Chapter 3

to define the programmer’s professional and social identity. By juxtaposing two historical episodes that are usually treated separately—automatic programming and software engineering—this chapter contrasts an earlier period of relative prominence for women with a later era in which masculine metaphors became dominant and female practitioners lost visibility. Programming innovations were not just technical milestones. They were also social commentary, because each new method reflected ideas about labor and gender. Labor tensions stemmed from competing visions of how software production would evolve. Programmers who promoted new tools hoped to liberate themselves from drudgery and empower themselves to do more interesting work, whereas some managers hoped that the new methods would deskill, discipline, or eliminate programmers. Gender played an important though subtle role in these developments. Women, by socialization as well as job placement, tended to be concerned with satisfying end users, and this standpoint motivated many women to create new software tools to meet customers’ needs. Sex discrimination in promotions also meant that women were often left out of public discussions of management techniques. Perhaps because of this, the software management debates of the 1960s ignored what could be considered the elephant in the room: the traits that managers found most problematic in programmers were those stereotypically associated with men. Finally, the adoption of the term software engineering in the late 1960s allied programming with a highly masculine area. This offered a positive model for male practitioners, implicitly promising that they—simply by virtue of being men—were likely to excel at software production. Conversely, the choice of engineering as a metaphor may have had adverse consequences for women’s participation. The following sections describe the evolution of these innovations and debates from 1950s automatic programming to 1970s software engineering, unpacking their social messages and concluding with reflections on their consequences for the future of programming. Visions of Automatic Programming Surely the days of programming, as we know it, are numbered. . . . Instead, we’ll express our intentions about what should be done. . . . Then these expressions will be submitted to immense, intelligent, intention-understanding programs, which will themselves construct the actual, new programs. We shall no longer be burdened with the need to understand all the smaller details of how computer

Software Crisis or Identity Crisis?   75

codes work. All that will be left to those great utility programs, which will perform the arduous tasks of applying what we have embodied in them, once and for all, of what we know about the arts of lower-level programming. —Marvin Minsky, 19832

When artificial intelligence (AI) visionary Marvin Minsky wrote these words in 1983, the dream of having a computer program itself was already three decades old. In the early 1950s, this ideal was called automatic programming, a term that was in common use by 1952.3 It was still current in 1961 when another AI notable, Herbert A. Simon, predicted that “the programming occupation will become extinct (through the further development of self-programming techniques).”4 Grace Murray Hopper laid out one of the earliest descriptions of the new approach in her widely cited article “The Education of a Computer,” which she first presented at the May 1952 ACM national meeting. There Hopper boldly proclaimed, “It is the current aim to replace, as far as possible, the human brain by an electronic digital computer.”5 From a twenty-first-century perspective, such predictions seem foolishly optimistic and badly off the mark. Programmers have not become obsolete. The number employed increased steadily throughout the 1950s and 1960s, when these predictions were being made, and by 2008 over a million programmers were working in the United States alone.6 And programming is still considered “brain work,” a skilled occupation whose practitioners are typically college educated. Did experts like Hopper, Simon, and Minsky truly believe that programming would be completely eliminated through automation? This section solves the mystery of the nonvanishing programmer by showing how technical innovations of the 1950s dramatically changed the practice that had been designated by programming without making the job category itself obsolete. I then consider the labor and gender dynamics that fueled debates over automation. Technical Innovations in Programming in the 1950s Creating a computer program that performs useful work for the end-user requires a series of steps. The first is analyzing the problem—talking with the customer or studying the application area to determine what problem the program should solve and then specifying a general method for solving it. Next, this general method must be translated into an organized

76  Chapter 3

series of mathematical or logical operations, which are then coded into a computer language. The code must then be tested, debugged, and documented. The amount of time that these stages take and the burden of errors that they produce depend on a number of factors, including the type of application, the capacities of the computer, the tools available, and the workers’ skill. Because all of these factors have changed over time, what it means to eliminate programming problems—or to eliminate programming itself—has also changed over time. For the scientific applications that the earliest computers were designed to tackle, the analysis phase was relatively straightforward, since the problem was usually already expressed in mathematical terms. The coding phase, however, was time-consuming and fraught with error, and debugging took much more time than anticipated. EDSAC (Electronic Delay Storage Automatic Calculator) (figure 3.1) creators Maurice V. Wilkes, David J. Wheeler, and Stanley Gill confessed as much in The Preparation of Programs for an Electronic Digital Computer (1951), which is widely considered to be the first programming textbook. The authors noted that “Experience has shown that such mistakes are much more difficult to avoid than might be expected. It is, in fact, rare for a program to work correctly the first time it is tried.”7 The first programming languages, called machine languages, specified only the most basic hardware operations, such as copying the contents of a memory location to the machine’s adder or multiplier. Any task beyond basic arithmetic had to be built up from a lengthy sequence of these simple machine operations, making the resulting programs difficult to understand or debug. Programmers also had to accommodate each computer’s quirks and limitations, especially the tiny amount of memory in the early machines. One of the trickiest chores was handling floatingpoint operations. (Floating-point notation represents a real number as a base multiplied by an exponent; since the exponent can change from one number to the next, the decimal point can be thought of as “floating” to the left or right.) Until the IBM 704 provided floating-point hardware in 1954, programmers had to manually rescale floating-point numbers during a calculation to ensure that significant digits were not truncated.8 Scientific programmers thus had to expend considerable effort simply to represent numerical data accurately, quite apart from performing any calculations on it.

Software Crisis or Identity Crisis?   77

Figure 3.1 EDSAC I with Maurice V. Wilkes and William (Bill) Renwick.

From a programmer’s perspective, then, many “software” problems were actually caused by the inadequacy of the hardware. People were shouldering some of the load that the machine should have carried, and automating low-level coding, memory management, and scaling tasks would merely shift this burden back onto the machine, where it belonged.9 Rather than diminishing the creative side of programming work, automation would free up human beings to do more of it. Reflecting this view, the early improvements in programming methods—subroutines, compilers, and high-level languages—constituted a largely bottom-up movement by programmers themselves who wanted to achieve better results with less drudgery. Labor, rather than management, led the way. The earliest attempts to improve programming practice sought to reduce coding time and errors by reusing portions of working programs, so that fewer pieces of code would have to be written and debugged from scratch. These reusable sections of code became known as subroutines. At

78  Chapter 3

the Harvard computation lab during World War II, for example, Hopper and her colleagues kept a notebook of completed programs and copied sections of these programs for use in new programs.10 EDSAC largely automated the process of using subroutines, and the Cambridge staff quickly developed an impressive suite of subroutines that became a model for programmers in both the United Kingdom and United States.11 A series of incremental advances during the 1950s took programmers from using machine code plus subroutines to high-level languages that allow code to be written using English words or mathematical notation and that provide simple ways to specify the logical flow of a program. The earliest systems that provided programmers with a language other than machine code were pseudocodes, which resembled machine code but specified more complex actions than the machine’s hardware could actually perform. A program written in pseudocode had to be interpreted by another program that would translate the code line by line into machine instructions, executing each instruction before moving on to the next.12 In 1951, Hopper, then head of programming for UNIVAC, took a decisive step toward high-level languages with her most significant invention—the compiler. With the interpreter system, the pseudocode had to be reinterpreted each time that it was run—a painfully slow process on contemporary machines. In contrast, Hopper’s new program, called A-0, would read through the pseudocode and compile the specified subroutines into a complete program in machine code. The resulting program could then be executed as often as desired without having to recompile the pseudocode each time, promising significant time savings. Another advantage was that because the compiler examined the entire program before translating it into machine code, it could determine the amount of memory that was needed for subroutines and data storage and assign physical memory locations automatically, eliminating those chores for the programmer. For computer manufacturers and marketers, there was also a symbolic appeal. Unlike interpreters, the compiler created a program: the machine was “programming itself.” Hopper continued to refine her invention, and by 1953 her third compiler, A-2, was in trial use at a number of Remington Rand installations (figure 3.2).13 Others soon followed Hopper’s lead in developing new programming languages. The first widely used high-level language was FORTRAN (IBM Mathematical Formula Translating System), which was developed

Software Crisis or Identity Crisis?   79

Figure 3.2 Grace Murray Hopper presiding over the programming group at Eckert-Mauchly Computer Corporation (EMCC), ca. 1949.

between 1954 and 1957 by a team at IBM led by John Backus.14 Although FORTRAN made it possible to write programs much faster, it was really the quality of IBM’s FORTRAN compiler—which produced code as efficient as that written by hand—that won over programmers. As Lois Haibt, a member of the FORTRAN team, recalled, “There were a lot of people who would look at the code and say, ‘I can do better by hand; they can’t possibly do it as well,’” but “The people who actually tried it were convinced.”15 Another important algebraic language, called ALGOL (Algorithmic Language), was conceived by a committee of European and American computer scientists in 1955, with the first specifications published in 1958.16 The first business programming language was created by Hopper in 1955. With her usual terseness, she called the new language B-0, but it was renamed FLOW-MATIC when Remington Rand released it to customers in 1958. FLOW-MATIC was both popular with users and

80  Chapter 3

an influential model for the first truly standard programming language, COBOL (Common Business-Oriented Language), which was developed in 1959 by a committee representing the U.S. government and the computer industry. It quickly became the standard for commercial data processing—partly because COBOL programs could run on any type of computer and partly because the U.S. Department of Defense (which wanted the ease of using a single language) insisted that all of its computer suppliers provide support for COBOL. Thus, by the end of the 1950s, there were widely used languages for both scientific and business applications that eliminated many of the low-level tasks that had formerly occupied the time of programmers. Women were unusually prominent in this movement, given their small percentage of the computing workforce. One important female contributor was Betty Snyder (Holberton), a former ENIAC programmer whose work at UNIVAC inspired Hopper’s invention of the compiler. Snyder had created an important type of subroutine called a sort-merge generator, which allowed the programmer to specify a set of input files and the type of sort and merge operations to perform and then generated machine code for performing the specified actions. Hopper later lamented that Snyder had not received the recognition that she deserved for the sortmerge generator: “Everybody’s forgotten that she wrote the first program that wrote a program. . . . I’m not sure that I would necessarily have gotten done what I did get done if she hadn’t been ahead of me, so to speak. Knowing that she had used a program to generate a program, I had a good deal more nerve to go ahead and build the first A-0 compiler.”17 Other female innovators included Adele Mildred Koss, also at Remington Rand, who created the first editing generator. This produced code to format data for output to tape or printers, reducing the time that was needed for this task from weeks to minutes. Nora Moser at the Army Map Service contributed an improved and widely used Editing Generator, and Mary Hawes of Burroughs coauthored an editing routine called Prefabtab for tabulated data.18 In the development of higher-level languages, Lois Haibt was a member of the nine-person FORTRAN team, responsible for flow analysis.19 Mary Hawes was one of several women who took leading roles in creating COBOL in 1959; she initiated the effort to produce a standard business language and chaired the initial COBOL committee’s task group on data descriptions. The six-person committee

Software Crisis or Identity Crisis?   81

that actually developed the COBOL specifications included Jean Sammet from Sylvania and Gertrude Tierney from IBM.20 Women may have been uniquely situated to participate in these innovations because of their gendered role in the workplace. As working programmers—and as the staff members who stereotypically were asked to assist customers or in-house users—women had both the expertise to devise solutions and the incentive to make programming easier for experts and novices alike. And although women usually lacked the formal authority to impose workplace practices, this was unnecessary in a computer culture that left the choice of techniques largely up to programmers themselves. As will be shown in the case of Hopper, women’s ambiguous position in the workplace also exposed them to the tensions that were inherent in the automatic programming vision. Debates over Automatic Programming: Eliminating or Elevating the Programmer? According to Herb Grosch, an influential industry pundit, practitioners in the mid-1950s were “divided into two camps—the ‘space cadets’ and the ‘neanderthals,’” who respectively supported and opposed automatic programming.21 Space cadets saw a future where programming would be fast and easy and software would be efficient and bug-free. They often dismissed their critics as clinging to outdated techniques. Yet as computer scientist James Tomayko has pointed out, many respected members of the community had doubts about automatic programming.22 Even FORTRAN creator John Backus admitted that the first automatic programming methods had been “clumsy and slow” and that “purveyors of snake oil” had claimed that these systems “had mysterious, almost human abilities.”23 But debates over the new methods went beyond strictly technical issues. (Indeed, rapid improvements in compilers and other tools had dispelled much of that criticism by the early 1960s.)24 Ultimately at stake was the professional identity of programmers and their relationships with end-users, managers, and hardware engineers. Would programmers be deskilled, perhaps even replaced by their own users? Or would they be empowered? Gender was also part of this contested identity, since certain roles in the computing workplace were tied to the sex of the worker. These labor and gender tensions can be seen in the writings of Hopper, the foremost evangelist for automatic programming. Hopper tirelessly

82  Chapter 3

promoted compilers and other new techniques, traveling across the United States to give talks and helping to organize two symposia on automatic programming that were sponsored by the Office of Naval Research.25 As a female software expert, Hopper occupied an ambiguous position. Her ambition and talent had earned her a leading role in both government and industry circles, but she never fully adopted a management perspective, since women had no realistic hope of rising into the upper ranks of computer firms. Instead, Hopper occupied a more complex standpoint where the technical, managerial, and customer spheres overlapped. As a programmer, she was aware of both the tedium and the creative potential of her craft; as an advocate for Remington Rand’s customers, she realized that the old methods were a barrier for novice users; and as a representative of a large employer of programmers—the U.S. Navy—she was sensitive to its managers’ desire to produce faster, better, more comprehensible code. But although all these groups could potentially benefit from the new methods, the potential conflicts among them complicated Hopper’s attempts to frame a uniformly appealing vision of automatic programming. Hopper’s brash claim in “The Education of a Computer”—that a computer could replace the human brain—probably reflected overenthusiasm for her newly invented compiler, but it also had a grain of truth, since in actual practice, the majority of a programmer’s time was spent on routine work. Under these conditions, Hopper noted, “the novelty of inventing programs wears off and degenerates into the dull labor of writing and checking programs. This duty now looms as an imposition on the human brain.”26 To her fellow programmers, Hopper was saying that compilers and subroutines could indeed take over “brain” work—but only work that the human brain should never have been saddled with in the first place. Yet she wrote a few pages later, “Stated bluntly, the compiling routine is the programmer and performs all those services necessary to the production of a finished program.”27 This seemed to promise employers that they could fire their programmers. Indeed, her awareness of management’s financial concerns surfaced in an aside where she noted that “with the computer paid for, the cost of programming and the time consumed comes to the notice of vice-presidents and project directors.”28 In an awkward attempt to reconcile these contradictory visions of the programmer as skilled inventor or unnecessary expense, Hopper drew a distinction

Software Crisis or Identity Crisis?   83

between two categories of programmer—the novice, whose job would be automated, and the expert, who would still be needed to craft the compilers and subroutines that allowed automation. Hopper’s vision had evolved by the time she spoke at the May 1954 Office of Navel Research Symposium on Automatic Programming for Digital Computers, an event that she helped organize. Here she decisively rejected the notion that the programmer would be replaced by a machine. She began her talk with an expansive definition of the programmer’s responsibilities, which included “numerical analyst, encoder-decoder, electrical or electronic technician, detective and bug-hunter, and finally, evaluator.”29 Although she saw this all-encompassing job as one that would gradually be divided among “the analyst, programmer, coder, operator, and maintenance man,” her description of the programmer retained analytical expertise: “A ‘programmer’ prepares a plan for the solution of a problem,” which “may or may not include numerical and systems analysis.”30 The plan, represented by a flow chart, would then be passed down the job ladder to a “coder”—a low-level programmer who wrote machine instructions but did not plan the overall program. As noted in chapter 2, such a division of labor between coders and programmers was far from a universal labor practice, but for Hopper, it served an important rhetorical function: it allowed her to assert that certain tasks could be automated without devaluing the status of programmers like herself.31 The coder now occupied the expendable position that the “inexperienced programmer” had in her earlier piece. As Hopper put it, “It is this function, that of the coder, time-consuming and fraught with mistakes, that is the first human operation to be replaced by the computer itself.”32 From then on, she used the term automatic coding rather than automatic programming. As she argued at a 1961 conference, “Work in automatic coding has concentrated on getting rid of the coder. We have not yet tackled the job of automatic programming.”33 Contemporary writings reveal other tensions that surrounded the programmer’s professional identity. Some programmers hoped that the new methods would give software the same cachet as hardware and elevate programmers to a status equal to engineers. Unlike the later discourse of software engineering, which assumed the superiority of engineering and argued that programmers must emulate engineers, these earlier commentators positioned programming as an independent endeavor with its

84  Chapter 3

own achievements. Indeed, they claimed that software could correct the shortcomings of hardware, arguably placing the programmer above the engineer. For example, Wilkes, Wheeler, and Gill wrote that floating-point subroutines provided the programmer with the equivalent of “an entirely new machine” that was easier to use.34 Such arguments may have had a particular appeal for women, who were largely excluded from engineering. At the 1954 Office of Naval Research symposium, Nora Moser proposed that “Any reasonably good compiler . . . is a pseudocomputer” and that such “computers” designed by programmers were superior to the ones built by engineers: “A compiler is a much more convenient and flexible computer than a UNIVAC or a 701 or a SEAC. . . . There is no limit to the number of commands.”35 Grace Murray Hopper expanded on Moser’s remark: “Thus a ‘second-level’ of computers is being ‘built.’ Computers with a wide range of instructions, easy to program, and able to be shipped by mail.” Hopper boldly invited mathematicians who were researching designs for new computers or languages to sidestep the engineers and work directly with programmers.36 Such rhetoric portrayed programmers as the masters, not the victims, of automation, and the female-friendly field of software as every bit the equal of the masculine domain of engineering. Perhaps the most heated area of debate over the labor implications of the new methods concerned whether end-users could take over programming from professionals. One of the earliest expressions of this claim appears in the forword to the 1951 edition of Wilkes, Wheeler, and Gill, which boasted that the use of subroutines “divests programming of the appearance of being something of a magic art, closed except to a few specialists, and makes it an activity simple enough to be undertaken by the potential user.”37 J. Robert Logan, who helped implement a pseudocode for UNIVAC called the Short Code, asserted in 1955 that “By means of the Short Code, any mathematical equations may be evaluated by the mere expedient of writing them down” so that “the need for special programming has been eliminated.”38 In both cases, however, the user was understood to be a trained mathematician or scientist. With the appearance of English-language compilers in the late 1950s, this vision expanded to include nontechnical business users. Stephanie Shirley, who started a contract programming company in the early 1960s (see chapter 4), later recalled, “When COBOL was introduced, we thought

Software Crisis or Identity Crisis?   85

that would be the end of the company, that nobody would be buying software anymore—programming—because it was just so easy.”39 Computer manufacturers eagerly promised customers that they would soon be able to remove their programming staff from the payroll. A Remington Rand ad from 1955 crowed, “Now . . . Univac Tells Itself What to Do!” adding that “Univac now automatically produces complex coded routines when given a simple instruction” (figure 3.3).40 The accompanying image of an executive triumphantly tearing up a sheaf of coding sheets seems to be a thinly veiled metaphor for firing the programmers who would have used them. A brochure for Bendix computers from the same year promised customers that if they used Bendix’s compiler or interpreter, “With just four hours of instruction, personnel who have had no computer experience can easily solve long and complex problems.”41 Of all the discourses surrounding automatic programming, these marketing efforts aimed at managers come the closest to invoking a classic labor-management conflict, with automation leading to deskilling or unemployment of formerly skilled workers. A century of industrial conflict gave deep cultural resonance to the hope or fear that these new technologies would downgrade human skills.42 In the 1950s, such anxieties focused on computers, which were poised to replace workers through factory and office automation—so why not through the automation of programming itself?43 Sociologists Philip Kraft and Joan Greenbaum, who studied programming labor in the 1970s, concluded that managers were using techniques such as highlevel programming languages to deskill and dominate workers.44 More recently, some historians of computing have agreed that eliminating programmers was a major aim of automatic programming (although they generally conclude that it was unsuccessful).45 But on closer examination, automatic programming does not fit the classic deskilling model. Unlike most industrial or office automation, software innovations were created and adopted by programmers themselves, not managers. Neither proponents nor opponents were primarily concerned with deskilling. In fact, some managers worried that compilers would require programmers to become more skilled.46 Rather than a serious goal, deskilling functioned more as a handy cultural trope that marketers could use to appeal to potential customers.

86  Chapter 3

Figure 3.3 “Now . . . Univac Tells Itself What to Do!” Remington Rand ad, 1955.

Software Crisis or Identity Crisis?   87

Some programmers, such as Hopper, were keenly aware of this misappropriation of their efforts. Interviewed in 1980, when she no longer worked for Remington Rand and could speak freely, Hopper dissociated herself from the term automatic programming. After interviewer Angeline Pantages noted that Hopper’s team had been called the Automatic Programming Group, Hopper derided the name as mere marketing hype: “I didn’t name it that. The sales department did. .  .  . I always disliked that phrase. We still had to tell the compiler what to compile. It wasn’t automatic. The way the sales department saw it was we had the computer writing the programs; they thought it was automatic.”47 In a letter to the Communications of the ACM in 1959, Eugene H. Jacobs of the RAND Corporation objected to the term automatic programming for high-level languages, arguing that “none of them do much about the difficult parts of the programming job.” He insinuated that computer manufacturers, rather than using the more “honest” term automatic coding, were intentionally misleading the public in an effort to sell their wares.48 Gerald Weinberg, a well-known software developer at IBM in the 1950s, echoed this assessment in 1971: “Some years ago, when COBOL was the great white programming hope, one heard much talk of the possibility of executives being able to read programs. With the perspective of time, we can see that this claim was merely intended to attract the funds of executives who hoped to free themselves from bondage to their programmers.”49 The deskilling trope was also used by some “space cadets” to dismiss their “neanderthal” critics as merely being afraid for their jobs.50 This jab played on the strong cultural association between automation and unemployment, but the argument was self-contradictory. For programmers to be worried about their jobs, they would have to believe that compilers worked well enough to revolutionize software production—yet the “neanderthals” were also accused of stubbornly regarding compilers as useless.51 Automatic programming boosters sometimes portrayed the naysayers as a priesthood whose members were clinging to their monopoly over esoteric skills. Backus, for example, scoffed that “many programmers of the freewheeling 1950s began to regard themselves as members of a priesthood guarding skills and mysteries far too complex for ordinary mortals” and “were thus unalterably opposed to those mad revolutionaries who wanted to make programming so easy that anyone could do it.”52 Yet there is little if any firsthand evidence of programmers who worried

88  Chapter 3

about losing their jobs to users—at least after the initial hype about the new techniques faded. Indeed, given the tight labor market for programmers throughout this period, such a fear would have made little sense. Invoking a priesthood that was fearful of losing its privileges was more likely a rhetorical effort to discredit serious criticisms of the new techniques. For both proponents and skeptics, debates over automatic programming were as much about asserting a professional identity as about the merits of particular techniques. The Fate of Automatic Programming In many ways, the campaign for automatic programming was a rousing success. The new techniques were widely adopted, and as promised, they greatly reduced the time that was needed to produce programs and transferred much tedious work from humans to machines. Many programmers took advantage of these new tools to improve the organization of their programs, creating a visible, logical structure that made code faster to produce and easier to maintain, reuse, and share.53 However, to the disappointment of some, the overall effect of compilers and associated tools was not to eliminate programming but to redefine it. Much of what had been included as an integral part of programming practice—tedious copying or recoding of subroutines, the need to be aware of machine design and physical memory configuration, and the use of machine codes—was no longer required. But the programmer still had to design and specify the higher-level structure of the program, tasks that proved too complex for most end-users. The new techniques also did nothing to automate the initial analysis of the problem—the task of modeling a real-world activity as an ordered flow of computable steps. Although this work could potentially be shifted from the programmer to a systems analyst, in either case it was a person and not the computer that performed it. To the extent that a factory-like version of automation failed to materialize, it vindicated programmers’ holistic view of their work as complex and creative. It also reflected a conscious decision by computer manufacturers and their customers to use automation to increase productivity and quality rather than to shrink the labor force. Managers asked programmers to tackle more ambitious projects or create more sophisticated user interfaces, expanding their demand for skilled labor to absorb the available supply. The ever-increasing complexity of cutting-edge systems would soon lead to new calls for a reform of programming methods.

Software Crisis or Identity Crisis?   89

Constructing a Software Crisis A good 90 per cent of all programming projects overrun their initial time estimates, and properly functioning programs completed on time are as rare as unicorns.54 —“Maximising the Productivity of Programmers,” 1973

Software production in the 1960s was challenging on many fronts. Programmers struggled to make full use of a steady stream of hardware improvements, such as a tenfold increase in memory size and speed between 1960 and 1965.55 The bulk of user applications shifted from the elegant simplicity of mathematical equations to the real-world messiness of business processes. Computer manufacturers were trying to develop a new type of software, operating systems, which were forbiddingly complex since they had to provide an interface between the computer and all of the other programs that were running on it. Larger projects often meant larger programming groups, creating coordination and communication issues on top of the technical challenges. By the late 1960s, the size, novelty, and complexity of the programs that were being attempted had led to some spectacular failures, and some commentators claimed that a “software crisis” was at hand.56 Retrospective assessments by historians and computer scientists have been skeptical that the software crisis ever existed as a clearly defined event or problem. Tom Haigh has dismissed the crisis as existing more in the minds of historians than in the reality of practitioners.57 Martin Campbell-Kelly notes that the term had diverse interpretations in contemporary debates: “There were several software crises in the 1960s, apart from the programmer shortage: the low productivity of programmers, the poor reliability of programs, and cost overruns.”58 A 1998 article by a group of computer scientists went further, claiming that “The term ‘software crisis’ was coined to embrace all supposed ailments afflicting the production of software.”59 But even if the term itself was so broad as to be meaningless, it flagged some real concerns among software producers. The three that loomed largest in the computing literature of the 1960s and 1970s were a perceived shortage of programmers; production problems that caused projects to be late, over budget, and full of bugs; and a supposedly undisciplined labor force that failed to work effectively with management. The following sections probe the factual basis and social

90  Chapter 3

meaning of these concerns from gender and labor perspectives. It shows how the discourse of software crisis, by framing these problems in particular ways, identified certain types of people and not others as best qualified to solve the industry’s problems. Labor Shortage Since the earliest days of the postwar computer boom, it was a common observation that the demand for programmers outstripped the supply. Hopper and Mauchly warned in 1953, “The present shortage of trained programmers is not likely to be relieved in a short time, since new computers are going into use at an ever-increasing rate.”60 Historian Nathan Ensmenger places this deficit at the heart of the software crisis: “It would be difficult to overemphasize the degree to which the programmer labor shortage of the late 1960s dominated contemporary discussions of the health and future of the computer industry.” He cites industry studies that projected an increase in the number of programmers needed from 100,000 in 1966 to as many as 650,000 by 1970, along with fears that demand for programmers would drive up salaries.61 Commentators in the United Kingdom were equally dramatic. The Economist reported in 1967 that “There is a drastic shortage of good programmers; in Britain there are about 6,500 now with an estimated 63,000 needed by 1976.”62 How real was this labor shortage? The demand for programmers was evident. The U.S. Census Bureau reported that the number of employed programmers rose from 13,000 in 1960 to 258,000 in 1970, a twentyfold increase. But other indicators are ambiguous. In a labor shortage, one would expect salaries to go up, but programmers’ earnings do not seem to have increased faster than those of other technical workers. Between 1966 and 1970, wages for employed men in the United States rose 31 percent, while salaries for male professional engineers and technicians rose only 27 percent, and programmers were not at the top of this category. Male engineers earned a median salary of $13,149 in 1969, while the median for computer specialists was only $11,193. Female computer specialists had the highest median salary of any female occupation listed in 1969 (there was no category for female engineers), but it was still only $7,763, a bargain for employers compared to the male rate.63 These data are not comprehensive, but they cast doubt on the notion that programmers’ salaries were escalating beyond the means of employers.

Software Crisis or Identity Crisis?   91

As noted in chapter 1, the perception of a labor shortage often reflects deep-seated beliefs about gender. The overwhelming majority of programmers in the late 1960s were men, who made up about 80 percent of U.S. computer specialists.64 If programmers were really in such short supply, then why did employers not recruit and train more women—especially since, in those days, women could legally be paid less than men for the same work? Some employers did recruit women: IBM actively courted women with college degrees in math, and many businesses retrained female secretaries, cardpunchers, and accountants as programmers. But employers did little to question or alter the masculine bias that kept more women from being considered for programming jobs. For example, young women with scientific or technical ability were often socialized away from pursuing college degrees in these areas. Instead of encouraging women with nontechnical degrees (or no degree at all) to consider programming, employers were more likely to require a woman to have a technical degree.65 In the United Kingdom, as historian Marie Hicks has described, civil service requirements of the 1960s were deliberately structured in a way that kept female machine operators from being promoted to programming jobs, which government managers wanted to reserve for young men with presumed “management potential.”66 Employers did not try to appeal to women by ending wage discrimination, and few if any restructured their workplace to accommodate the desire of many women to maintain a programming career while having a family (see chapter 4). The point here is not that the computer industry treated women worse than did other employers; by many accounts, it treated them better. But probing behind the rhetoric reveals that the labor shortage really referred to a specific, privileged category of workers—male programmers with traditional technical qualifications and no childcare obligations.67 Production Problems Historians such as Mahoney have located the software crisis in the production process, as “large projects experienced large cost overruns, missed deadlines and failures to meet specifications.”68 Campbell-Kelly and Aspray have attributed these problems in part to the increasing size and complexity of the programs being attempted: “Projects involving a million lines of code frequently ended in disaster. The 1960s was the decade of the software debacle; and the biggest debacle of all was IBM’s

92  Chapter 3

operating system OS/360”—a year late, four times over budget, and full of bugs.69 In another well-publicized mishap, the National Aeronautics and Space Administration (NASA) was forced to destroy the Mariner I spacecraft just minutes after its July 1962 launch because of a software glitch. Although these incidents were real, their causes and their frequency were matters of interpretation. In a more recent book on the software industry, Campbell-Kelly has revisited the idea that software products were chronically late, over budget, and bug-ridden, calling this view “exaggerated” and based on anecdotal evidence. He argues that dramatic problems were associated mostly with exceptionally large, one-of-a-kind programs rather than the prosaic business software that made up the bulk of actual programming practice: “It was mainly leading-edge projects and unseasoned development teams that experienced these problems. The great majority of projects were completed within budget and on time.”70 Contemporary sources from the business computing world made the same point. Ken Kolence of the early software company Boole and Babbage complained in 1968 that “I do not like the use of the word ‘crisis.’ It’s a very emotional word. There are many areas where there is no such thing as a crisis—sort routines, payroll applications, for example. It is large systems that are encountering great difficulties. We should not expect the production of such systems to be easy.”71 Choosing the most visible, rather than the most typical, examples to characterize the software industry added to a false sense of crisis. It also biased any solution toward techniques designed for large, complex systems. Joseph Cunningham, a software manager for the U.S. Bureau of the Budget and the U.S. Air Force and no stranger to large projects, noted in 1970, “What there is of management research and exploration generally deals with the most esoteric and mammoth of our applications, when in fact the preponderance of our computer inventory is at the other end of the spectrum.”72 In earlier decades, many software innovations had come from women who were working on business applications, but the crisis discourse redefined such work as unimportant compared to the large, complex, yet atypical systems that it privileged. Another dubious claim regarding software production was that programming costs were soaring so fast that they would soon dwarf the expense of computer hardware. This idea was popularized by Werner Frank of Informatics in a 1968 article, which included a graph showing that

Software Crisis or Identity Crisis?   93

programming had made up only 20 percent of the cost of running a computer installation in the 1950s but would rise to 80 percent of total costs in the future. History failed to bear out this claim, but as Campbell-Kelly documents, Frank’s ominous graph was “plagiarized, with random embellishments from one author to the next, well into the 1980s.”73 Frank himself recanted in 1983, writing that his casually sketched graph had unintentionally spawned a “myth” and admitting that software normally contributed less than half of the total computing cost.74 This myth reinforced a popular perception that programmer productivity was lagging, especially compared to the phenomenal advances in computer hardware. As Frederick Brooks pointed out in 1987, such a comparison was unfair: “the anomaly is not that software progress is so slow, but that computer hardware progress is so fast. No other technology since civilization began has seen six orders of magnitude in performance-price gain in 30 years.”75 The perception that programming labor was expensive and inefficient cast programmers as the problem behind the crisis. Unmanageable Programmers Ensmenger has argued that the supposed software crisis actually reflected a “struggle for organizational authority and managerial control” between programmers and their industrial and government bosses.76 He focuses on the idea that programming has always been “both art and science” and notes that managers found its creative, craftlike side worrisome because it confronted them with a work process that they could neither understand nor control. Above all, Ensmenger claims that employers of the 1960s regarded programmers as unmanageable, citing contemporary sources that branded programmers as “prima donnas” who were “arrogant,” “egocentric,” and devoid of social skills.77 Did managers really see programmers as recalcitrant prima donnas who must be put in their place? The 1970 compilation On the Management of Computer Programming provides a range of contemporary viewpoints on the subject. Some authors did take an adversarial stance toward programmers and sought a more disciplined workplace. Carl W. Clewlow of the U.S. Department of Defense argued that “from a management standpoint it is unacceptable to have valuable and costly resources operating behind a veil of mystery built on the premise that data processing is so different that it does not lend itself to some form of proper

94  Chapter 3

management controls and management disciplines.”78 Dick H. Brandon, who had been a manager at IBM and Diebold, bemoaned the fact that programmers’ labor-market power undermined “the normal employeremployee relationship, which, in part, depends on the fear of termination or disciplinary action.”79 Brandon even cast programmers as mentally unstable—“independent to the point of mild paranoia . . . slightly neurotic, and bordering on a limited schizophrenia”—as well as suspiciously nonconformist.80 He claimed they were unusually likely to sport “beards, sandals, and other symbols of rugged individualism” and that, most damning of all, “Two of the leaders of the Haight-Ashbury hippie movement were computer programmers.”81 But M. H. Schwartz, a former manager at the Federal Reserve and the Atomic Energy Commission, took issue with Brandon’s diatribe, saying programmers were simply responding to job stress: “The so-called prima donnas, in my view, were not prima donnas before they were immersed in a difficult [work] environment.”82 Schwartz felt that managers themselves often lacked professionalism, hoarding information and relying too much on “crash projects” because of poor planning.83 Carl H. Reynolds, president of the contract software firm CUC, argued that even though programming was an “intellectual activity” and an “art,” it was still possible to manage programming projects effectively by creating measurable milestones.84 Reynolds had earlier faulted managers for failing to motivate their programming staff properly: “The problem of motivating people to complete the job in the least possible time is a task too often left to an inflexible schedule commitment, rather than to the other techniques of management.”85 Other contributors echoed the idea that managers, not programmers, were to blame for production problems. George F. Weinwurm of Systems Development Corporation turned the cliché that programming was a “black art” rather than a science on its head, arguing that “the management of computer programming is still something of a black art.”86 Referring to an SDC study of fifty-five organizations that had found rampant deficiencies in “cost estimating, resource allocation, and scheduling,” he concluded that programmers were actually better at these tasks than managers: “At this stage . . . the most reliable predictive system is an experienced programmer.”87 He quoted approvingly a 1966 article by Frederick R. Kappel, chief executive officer of AT&T, that envisioned

Software Crisis or Identity Crisis?   95

programmers and managers working in harmony to create “a mixed team and a give-and-take, a creative dialogue, that develops in all members of the team a better understanding.”88 Even Frederick P. Brooks, who had had the dubious distinction of overseeing the OS/360 debacle at IBM, never placed the blame on his programmers, arguing instead that bad schedule management had been the culprit.89 Overall, there seems to have been no consensus that programmers were inherently unmanageable. To the extent that programmers were indeed seen as problematic, it was a particular type of programmer who made managers uneasy. The traits that were singled out by contemporary commentators are those stereotypically associated with masculinity. Managers decried programmers who lacked interpersonal skills, who disliked collaborating or sharing ideas, and who were more interested in playing with the technology than producing useful results. Gerald Weinberg’s widely discussed 1971 book, The Psychology of Computer Programming, criticized the popular idea that programmers should be reclusive individualists. Weinberg, who had managed large software projects at IBM before starting his own consulting company, argued that software was produced most effectively in egalitarian teams that emphasized open communication among members. He devoted a chapter to what he called “egoless programming,” the idea that individual programmers should not become so attached to their code that they refused to take suggestions from others or submit their code to review. Instead, team members should share their code, which would help them find and fix bugs and also learn from each other. Weinberg contrasted his approach with what he saw as the macho attitude of many managers: “Managers tend to select themselves from the ‘aggressive’ component of society. . . . They are especially at a loss to understand the smooth functioning of a programming group based on mutual respect for individual talent and cooperation in the common cause.”90 Although Weinberg did not explicitly refer to gender, his contrast between egoless and egotistical programmers mirrored gender stereotypes, and his analysis struck a chord with several women that I interviewed. Marlene Hazle, who worked at the MITRE Corporation, felt that Weinberg’s critique captured a “male” atmosphere of competitiveness in the early computer industry. Hazle reflected, “Where everybody was so new, ideally you would want to share anything that you learned with other people. But that’s not what happened. . . . I think that people were very possessive about the code

96  Chapter 3

they had written . . . and God forbid that somebody else should come in and change it!”91 Judy Clapp recalled the book as revolutionary: “When people wrote software in those days, they believed it was their property. . . . Egoless Programming [sic] was a book that came out that said, ‘Wait a minute . . . we are all here together, and everything you write is a contribution to the system, and you have to show this to people.’ Show people your code: . . . It’s hard to believe what a big step that was!”92 Software engineering advocate Barry Boehm referred disparagingly to “the Wyatt Earp Syndrome,” complaining at a 1979 conference about the uncommunicative programmer “who carries the critical program logic and design decisions around in his head, never documenting anything he does,” so that “when the inevitable crisis comes along, only he can save the situation, coming on like Wyatt Earp saving the town from the bad guys.”93 As Boehm’s cowboy imagery vividly suggests, the egocentric programmer was a decidedly masculine persona. To say that such traits are masculine is not to say that male programmers possessed them and women did not. On the contrary, a pair of studies in the Journal of Applied Psychology in 1967 and 1968 found that male and female programmers were remarkably similar in their outlooks. Programmers of both sexes expressed attitudes that seem to have made managers uneasy—a “disinterest in people” and a preference for “independent, nonroutine work.”94 But although women could share these traits, they were culturally associated with men. Indeed, the authors judged female programmers to be on the masculine side of a “masculinity-femininity” scale used by psychologists. Because masculinity is privileged in Western culture, the association of individualism, taciturnity, and competitiveness with masculinity may have made some programmers reluctant to alter these traits in favor of an “egoless” style. The management crisis could then be understood as a gender crisis—a problem that was caused by the overvaluation of masculine traits in the workplace. Insofar as the software crisis existed at all, it was neither a distinct event nor a coherent description of prevailing conditions in the industry. It may be better viewed as an all-purpose complaint that reflected inflated expectations, labor tensions, and gendered assumptions about who could do programming and how they should behave. The crisis rhetoric also provided a rationale for those who wanted to change the direction of programming. As computer scientist Hugh Robinson and his colleagues later

Software Crisis or Identity Crisis?   97

observed, “A crisis demands attention and resources. It sets agendas that help define the discipline that deems itself in crisis.”95 One such agenda was the attempt to reinvent programming as software engineering. Software Engineering: A Slogan in Search of a Meaning The phrase “software engineering” was deliberately chosen as being provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines that are traditional in the established branches of engineering. —Software Engineering, 196896

In October 1968, the Science Committee of the North Atlantic Treaty Organization (NATO) sponsored an international conference in Garmisch, Germany, to discuss concerns about software production. The invitationonly conference included fifty-seven participants from eleven countries. Almost half, including the three conference chairs, were from universities, half were from industry, and a few government representatives made up the remainder.97 The Garmisch organizers proposed what they claimed was a bold new approach—transforming existing programming practices into “software engineering.” Although the Garmisch conference did not instantly create a discipline of software engineering, it did establish the word engineering as a way to refer to software production, and other groups began to institutionalize the new paradigm. In the United States, the Institute of Electrical and Electronics Engineers (IEEE) and the Association for Computing Machinery (ACM) each formed committees on software engineering in 1975 and began publishing the IEEE Transactions on Software Engineering in 1975 and ACM Software Engineering Notes in 1976. The U.S. National Bureau of Standards and IEEE Computer Society coorganized a National Conference on Software Engineering in 1975, which grew into an annual international event with ACM as a cosponsor. Neither the British Computer Society nor the UK Institution of Electrical Engineers created committees or journals with the phrase software engineering, but the term became common in articles published by both groups.98 Despite its rapid rise, however, the concept of software engineering faced opposition from many computer practitioners who questioned both the feasibility and the desirability of techniques proposed under that banner. As with the phrase automatic programming, a main

98  Chapter 3

point of contention was the assumptions that proponents made about the nature of programming work. In the sections that follow, I argue that the word “engineering” should be seen a metaphor, not a simple description, and as only one of many possible models for programming. Even proponents of the engineering model had conflicting agendas and interpretations of what software engineering was or should accomplish. I discuss the gender implications of choosing engineering as a model for programming and ask whether software engineering fulfilled the technical, managerial, or labor visions of its proponents. Engineering as a Metaphor The term software engineering has become common enough today that its provocative effect has been lost. Yet when the term was introduced at Garmisch, it was purely aspirational. Rather than claiming to describe actual practices, the organizers named an ideal that did not yet exist. Nor was it obvious that engineering was the best model for programming. The computing literature of the 1960s is rife with competing metaphors, each of which was chosen to make a particular claim about the nature of programming. Some managers continued to view programming as a creative art or craft—and in a positive sense, rather than as a problem to be cured by imposing scientific rationality.99 In the academic community, computer science was often seen as a branch of mathematics, which had a higher intellectual status than engineering. The 1970 On the Management of Computer Programming, a book that targeted a business audience, ignored the new term software engineering and preferred to use managerial skill as its ideal.100 Maurice Wilkes argued in 1976 that the term engineering did not realistically represent the process of creating a large program. He suggested instead that “There are some analogies between writing a program and writing a treatise or a paper.”101 Computer industry writers invoked a host of other professions to emulate, including accounting (for its certification standards), medicine (for its skilled teamwork and strong professional societies), architecture (as a model for coherent design and precise specification), aviation (for its recognition of the dire consequences of failure), or even cooking (as a time-sensitive production process).102 Describing an organizational concept invented at IBM called the “chief programmer team,” Frederick Brooks sketched an almost comical mash-up of skilled occupations. His dream team consisted

Software Crisis or Identity Crisis?   99

of a “surgeon” (chief programmer) assisted by a “copilot,” a “toolsmith,” and a “lawyer”—but no engineers.103 Clearly, there was no consensus that programming should be uniquely identified with engineering. To assert this was to make a deliberate, even radical statement. Engineering had multiple connotations that could serve diverse agendas. For people who were directly involved with software production, it could mean having a set of clearly specified, standard techniques that produced measurable results. An important early technique that was associated with this idea of software engineering was structured programming, a concept articulated by Edsger W. Dijkstra in 1968.104 Responding to what he called a prevailing mood of “software failure,” Dijkstra aimed to provide some basis for believing that programs were logically and mathematically correct.105 The main tools of structured programming were abstraction, modularity, and the use of conditional loops (rather than “go to” statements) to model the logical structure of the process that was being automated. Structured programming was followed by efforts to provide robust techniques for other aspects of program production, such as design methodologies in the mid-1970s, architectures and objectoriented programming in the mid-1980s, and requirements analysis in the 1990s.106 It may seem straightforward to call the use of standard, tested methods engineering, but this label is in fact ideological since it implies that only engineering can offer a systematic methodology. This rhetorical move is apparent in the IEEE’s current (1990) definition of software engineering: “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.”107 Such wording implies that engineering holds a monopoly on “systematic, disciplined, quantifiable” techniques, making the IEEE definition as much a glorification of engineering as a description of it. Another issue is that some of the concepts claimed as part of software engineering—such as reusable software, modular programming, or machine-independent programs—actually predated it. They had been introduced through “automatic programming” techniques such as subroutines and standardized languages. Dijkstra himself gave credit to the early EDSAC programmers in his influential “Notes on Structured Programming”: “If closed subroutines had not been invented more than twenty years ago, this would have been the time to do it! In other words: we are returning to familiar grounds.”108 The fact that the techniques

100  Chapter 3

proposed by software engineering advocates were not so different from earlier efforts suggests that “engineering” represented more a change of identity than a change of practice. This brings us to a second motivation for adopting the mantle of engineering—its perceived social or professional status. Douglas McIlroy of Bell Labs complained at Garmisch that the image of programming as an art or craft gave it a lower status than engineering: “We undoubtedly get the short end of the stick in confrontations with hardware people because they are the industrialists and we are the crofters.”109 Frederick Brooks wanted software managers to have the credibility that he felt other engineers had when defending their estimates to the corporate brass: “It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data.”110 Laurie Keller, a computer scientist at the Open University who began her career as a programmer in 1968, described software engineering’s appeal as less about techniques than about identity: “I think rather than just say, ‘There are things that we can borrow from engineering which would be useful in computing,’ we’re really saying, ‘Gee, we’d really like to be engineers.’”111 In these examples, engineering is still associated with quantitative, science-based techniques, but the techniques are described as valuable not for their actual utility but for their higher status within particular work environments. For managers who wanted a more tractable workforce and more controllable work processes, engineering represented discipline, standardization, and predictability, as several historians have noted. Mahoney described the “industrial engineering” model as evoking a “software factory” in which “production by means of interchangeable parts was translated into such concepts as ‘mass-produced software components,’ modular programming, object-oriented programming, and reusable software.”112 He argued that “programming systems came to be viewed in terms of disciplining programmers.”113 Writing in the late 1970s, Kraft called structured programming “the software manager’s answer to the assembly line,” turning software into “a standardized product made in a standardized way by people who do the same limited tasks over and over without knowing (or needing to know) how they fit into the larger undertaking.”114 Structured programming does not necessarily imply a hierarchical system of deskilled labor; Dijkstra himself described programming as an “art.” But as MacKenzie notes, “Managers adopting the ideas

Software Crisis or Identity Crisis?   101

of structured programming may have hoped that they would increase direct management control over both programming and programmers” and points out that, to Dijkstra’s dismay, structured programming became linked with IBM’s “chief programmer team.”115 In this model, a single elite programmer did the design, and a team of other programmers did the coding under structured guidelines, which could be seen as demoting those programmers to mere coders. Maurice Wilkes even argued that the work-discipline connotation of “software engineering” was its only value. In his keynote address at the Second International Conference on Software Engineering in 1976, Wilkes grumbled, “To the extent that it underlines the fact that programming in a commercial software organization is work, not play, the term software engineering is a good one; otherwise, I am not too happy about it.”116 A different take on engineering came from academic computer scientists who hoped to get funding for their research. By the mid-1960s, a number of American and British universities had established computer science programs. Not all academic computer scientists identified with engineering: in the United States, computer science was more or less evenly split between mathematics and engineering departments, and in the United Kingdom, it was more concentrated in mathematics.117 Consistent with this mathematical bent, much of the research that was funded under software engineering grants focused on formal methods—mathematically based techniques for specifying, designing, and proving the validity of software systems. Mathematics carried more intellectual prestige, but engineering strategically straddled the worlds of research and practice, and using the label software engineering made it easier for academics to claim that real-world benefits would flow from government support of their work. Indeed, some industry participants at the Garmisch conference felt that the whole “software crisis” had been manufactured to garner support for a proposed software research center.118 That proposal never came to fruition, but other government funding was forthcoming. In the United States, the National Science Foundation started a program to fund software engineering in the mid-1970s, and the UK government funded a massive R&D effort from 1983 to 1987 called the Alvey Programme.119 Software engineering was sold to the UK government as the savior of British computer industry, which had fallen far behind the United States in size and influence. The Alvey Programme was to provide a bridge between academic research and industry, allowing new techniques to be

102  Chapter 3

commercialized faster.120 For academic researchers, the word engineering had a convenient ambiguity that could encompass both theoretical abstractions and practical tools. For the major organizations that were trying to define computing as a profession, embracing the term software engineering could signal a claim to professional turf rather than any commitment to engineering as such. The origins of one of the major groups devoted to software engineering, ACM’s Special Interest Group on Software Engineering (SIGSOFT), illustrates this dynamic. Computer scientist Tony Wasserman contacted the ACM president in September 1973 to ask permission to start a group “on Programming (or Programming Methodology)” that would focus on techniques such as top-down design and structured programming. The ACM president denied this request on the grounds that such topics could be handled by the existing group, ACM’s Special Interest Group on Programming Languages (SIGPLAN). “In early 1975, though, the IEEE Computer Society created a Technical Committee on Software Engineering and began publication of IEEE Transactions on Software Engineering,” Wasserman recalled.121 After pointing out that ACM’s rival, IEEE, was moving into this “important, emerging field,” he got the ACM president’s permission to start what became SIGSOFT. In Wasserman’s account, changing the proposed group’s name to “software engineering” did not necessarily denote anything different from “programming methodology,” but it did help him accomplish some institutional maneuvering. The new name differentiated his venture from the territory already claimed by SIGPLAN, and it also prevented the rival IEEE from monopolizing a trendy new specialty. In short, there was never a single, coherent meaning for the term software engineering. Individual programmers, managers, and computer scientists adopted the term to serve a number of diverse and potentially conflicting agendas. But one group was conspicuous by its absence—female software pioneers. Software Engineering as a Gendered Construct No women were included among the “experts” and “prominent leaders in the field” who were invited to the Garmisch conference.122 Especially striking is Grace Murray Hopper’s absence, given that she was a well-known evangelist for improved programming methods and was serving at the time as the U.S. Navy’s director of programming languages and language

Software Crisis or Identity Crisis?   103

standards.123 But Hopper was hardly alone as a female software innovator. One could equally well ask why women such as Nora Moser, Jean Sammet, and Mary Hawes had not earned a place at the table when software improvements were being discussed. If we take the goals of the Garmisch conference seriously—“to discuss possible techniques, methods and developments” for better software production and to provide “a signpost to manufacturers of computers as well as their users”124—then the absence of these female pioneers should give us pause. Women had not only helped create the compilers and high-level languages that provided a key tool for producing better code, they had also devoted their professional lives to mediating between manufacturers, programmers, and users, a key goal of the conference. Their exclusion suggests that the new paradigm of programming as engineering brought with it unspoken ideas about which gender could best elevate the practice and status of programming. If we focus on the word engineering as a label rather than the techniques themselves, the absence of women becomes less surprising. As noted in chapter 2, engineering was (and remains) a highly masculine field in the United States and United Kingdom. An article that appeared in New Scientist the same year as the Garmisch conference had to assure readers that “One need not be a ‘masculine’ female to go into engineering despite the popular image.”125 In this cultural context, the engineering metaphor could not be gender-neutral. Indeed, given the greater status assigned to masculine pursuits, it is conceivable that by choosing the engineering label—and omitting women like Hopper—the Garmisch organizers and their followers were distancing themselves, consciously or not, from an earlier era when programming had been seen as “women’s work.”126 If so, this would not be an isolated incident. As noted in chapter 2, David Alan Grier has documented how ENIAC creator John Mauchly deliberately chose an engineering term—program—to describe writing software (rather than the term plan that was used in feminine hand-calculating work) in an attempt to raise the status of computer work.127 Whether or not men were conscious of the gender connotations of engineering, women in the field were often all too aware of them. Some women who worked at firms with a strong engineering focus reported that programmers were accorded a lower status than engineers—and that programming was seen as less skilled because women did it. Recalling her dealings with the ENIAC and UNIVAC engineers, Jean Jennings laughed, “Oh, yeah: engineers think they’re much better than programmers. . . . I

104  Chapter 3

don’t know whether or not they were prejudiced because I was a woman or because I was a programmer!”128 Judy Clapp, who joined MITRE in 1958 as part of the team that was designing the SAGE air defense system, said that the close association of engineering with masculinity reinforced a gender hierarchy at the company in which women were hired at a lower classification level than men. In addition to sexism, she said, “It was also a snobbism about being an engineer or not. The company had a lot of engineers, and I remember arguing with people who [said] that ‘Engineering was much harder, much harder, than what ‘we women did’—than software.’”129 Fran Allen, who joined IBM in 1957 and became one of its most distinguished researchers, noted that “the value of programmers was not recognized for a long time” and that when she received her first IBM award in the 1960s for her Advanced Compiler System, “it was only engineering awards: there were no awards for programmers.” Evidently those making the award assumed that all IBM engineers were male, since the physical prize was “cuff-links and a tie-clip!”130 Given this gendered status hierarchy, some practitioners—women as well as men—may have believed that programmers would rise in stature by adopting the title of engineer. An unintended consequence of this move may have been to make programming and computer science less inviting to women, helping to explain the historical puzzle of why women took a leading role in the first wave of software improvements but become much less visible in the software engineering era.131 But before castigating software engineering as antiwoman, we must remember that the perception of engineering as masculine is itself a social construction, not a reflection of inherent sex differences. Indeed, software engineering may have provided a welcome entree into the engineering world for women who wanted to be engineers but felt blocked by gender bias. Some women who already identified as engineers welcomed what they saw as an engineering approach to computing. For example, robotics pioneer Ruzena Bajcsy got her first Ph.D. in electrical engineering in Slovakia before earning a Ph.D. in computer science at Stanford University in 1972. She noted approvingly that in the years since then, computer scientists had “brought in more scientific methodology—you know, old-fashioned engineering methodology—which in those days was not there.”132 Even Laurie Keller, who described engineering schools as uninviting to women, agreed that programmers could borrow certain useful techniques from that discipline:

Software Crisis or Identity Crisis?   105

“For instance, getting your requirements right initially; understanding the materials you’re working with.”133 Susan Graham, the daughter of a mechanical engineer, got her Ph.D. in computer science a few years after Garmisch and easily identified as a software engineer. Referring to the process of checking the semantics of a programming language, Graham characterized engineering practice as trial-and-error: “You write a compiler, and then you do a lot of testing against real programs, and you try to see whether the right thing happens. . . . And that’s why it’s engineering!”134 These examples demonstrate again the diverse meanings of engineering, as well as female practitioners’ ability to prioritize those aspects of engineering that matched their own needs, experiences, and values. Some aspects of the software engineering ideal appealed directly to preferences that were widely expressed by women, such as the desire to create something that would improve users’ lives. Edward E. David of Bell Laboratories expressed this philosophy at Garmisch in 1968: “Software engineering and computing engineering have an extremely important and nice aspect to them, namely that people want to work on things that meet other people’s needs. They are not interested in working on abstractions entirely; they want to have an impact on the world.”135 Mary Shaw, who helped establish Carnegie Mellon University’s Software Engineering Institute in the 1980s, echoed this public service ethos in her own 1990 definition of engineering as solving “practical problems . . . in the service of mankind.”136 In her view, key aspects of an “engineering attitude” included “considering users” and realizing that design choices had to be made “for both technical and nontechnical reasons.”137 Shaw’s emphasis on users and on real-world, nontechnical factors fits well with the computer-as-tool orientation more common among women. Although engineering as a profession has been highly masculine, engineering as a discipline or philosophy has had a wider range of potential meaning. The Fate of Software Engineering We put a man on the moon. So why can’t we make software that works? —“Learning from Software Failure,” 2005138

As a metaphor for programming and an occupational category, software engineering has been a tremendous success. Over one million people are expected to hold jobs as software engineers in the United States by

106  Chapter 3

2018.139 Software engineering thrives as a focus for journals and conferences and as a collection of widely used (but also hotly debated) tools and methods for designing, writing, and testing programs.140 Yet computer scientists and programmers continue to question whether software engineering is—or ever will be—a real engineering discipline. Phrasing the question in that way implies that there is some unproblematic definition of engineering to which we can compare software production, but engineering as a metaphor for programming embodied many contradictory agendas. To some, it meant empowering and professionalizing programmers, and to others it meant deskilling and disciplining them. Some gauged its progress by the publication of theoretical research, and others wanted to see practical results for real-world projects. These conflicts were papered over by the common use of the software engineering label, and they persist to this day, undermining attempts by some to stabilize software engineering as a coherent discipline. In at least three important senses, software engineering could be said to have failed. First, because of the divergent approaches and priorities of academic theorists and industry practitioners, much research investment has been wasted. Second, to the extent that software engineering was meant to revolutionize labor practices by deskilling and disciplining programmers, imposing standardized research-based methods, or mandating licensing, it has not succeeded. Finally, software engineering never solved the problem that was its raison d’etre—the software crisis. These failures call into question the notion that engineering is the most appropriate model for the programming profession. As a research area, software engineering garnered funding and academic stature but was less successful at translating theory into practice. Bruce Barnes, who headed the National Science Foundation program that funded software engineering research from 1976 to 1986, was candid in a 1990 interview about the limited impact of the program: “That has been frustratingly slow in producing notable results—very slow. . . . There has been a lot of research in software engineering [on] how do you go about building things? What is the process you follow? And just about everybody has their pet way of doing it. And we have been fairly unsuccessful in being able to really evaluate those.”141 An assessment of the UK Alvey Project lamented that “Software engineering, the centerpiece of the program and the one most intended to lead to [commercial] exploitation,

Software Crisis or Identity Crisis?   107

produced no marketable output at all.”142 The elaborate formal methods that were developed were unsuited to the small software houses that made up the bulk of the UK industry, and this lack of fit kept software engineering from significantly improving the competitiveness of the UK software industry—which had been the rationale for funding Alvey in the first place. Campbell-Kelly, having described how the United States and Europe poured money into academic software engineering, concluded that “These policy decisions have often flown in the face of evidence suggesting the absence of any real link between R&D expenditure and industrial success.”143 The disconnect between research and practice can be traced to the conflicting meanings of engineering for theoreticians and practitioners, for whom software engineering had always been more a marriage of convenience than a coherent shared vision. Paula Hawthorn, a former programmer who started her own management consulting company in the 1980s, expressed frustration with the researchers’ failure to produce “workable” tools and their implied attitude of superiority to the community of working programmers: “The things that they are recommending that people do to change processes and all of that: none of it is really taking with the community—and there’s a reason for that. It isn’t that the community is stupid; it’s that there’s nothing that’s really working very well.”144 Writing from the other side of the divide about the “Prospects for an Engineering Discipline of Software,” academic Mary Shaw reluctantly concluded in 1990 that “Computer science has contributed some relevant theory, but practice proceeds largely independently of this organized knowledge. Given this track record, there are fundamental problems with the use of the term ‘software engineer.’”145 As an approach to organizing labor, software engineering was no more successful than automatic programming in reducing the skills and autonomy of programmers. Mahoney noted that some software development tasks were automated or rationalized but that “programming ‘in the large’ remains a labor-intensive form of craft production” and “the production of programs remains in the hands of programmers.”146 But not everyone had aimed to deskill programmers in the first place. Software engineering advocates such as Dijkstra and Brooks identified as programmers themselves and had no desire to downgrade their peers. Many programmers actively took up techniques such as structured programming

108  Chapter 3

as a way of easing their work and enhancing their own value in the job market.147 Rather than making programmers obsolete, software engineering methods became simply another skill that programmers could claim. Ironically, although some of the original proponents of software engineering equated engineering with tight management control over a disciplined workforce, this perception was changing in mainstream engineering. An article that surveyed the literature published since 1988 on managing scientists and engineers observed that “Traditional technical managers managed scientists and engineers through command and control systems” and “made sure [that they] followed directions and complied with these plans, procedures, and rules,” but it found that the more recent consensus was that managers should switch to a “leadership approach.”148 “Leaders” encourage their technical personal to be self-directed: “they assign scientists and engineers broad objectives, and create a work climate that helps them define and control their work,” and the result is that “a stimulating work environment substitutes for the need to direct the work of scientists and engineers.”149 Mainstream engineering seems to have moved in a direction that resembles early computing culture rather than vice versa. The problems that concerned the computer industry in the 1960s are still alive in the professional literature, and so is the term crisis itself. Brooks famously warned in 1987 that there was “no silver bullet”: software engineering tools and methods could help incrementally, but they would never solve the “essential” problem that conceptualizing and designing a system is an inherently difficult process.150 A 1994 Scientific American article called “Software’s Chronic Crisis” quoted dire figures about the failure rates of recent large-scale projects, such as the Denver airport’s automated baggage-handling system.151 James Bach, author of a software engineering textbook, observed in 1995 that “Our industry still has great difficulty consistently developing reliable software. We’ve tackled the problem from every direction, it seems, but projects and products continue to fail with alarming regularity. We shake our heads and mutter something about a ‘software crisis.’”152 At a 1996 conference on the history of software engineering, computer scientist David Lorge Parnas referred to the field as “an unconsummated marriage” between engineering and the “science of programming,” and Reinhard Keil-Slawik mourned that “there is definitely what might be called an identity crisis.

Software Crisis or Identity Crisis?   109

A strong indicator for this phenomenon is the fact that after more than 30 years computer scientists are investigating the history of other established branches of engineering to find out (or to define?) what should be done to turn software engineering into a sound engineering discipline.”153 After the U.S. Federal Bureau of Investigation spent $170 million on a faulty system that it abandoned—unused—in 2005, the IEEE Spectrum ran a special issue on software failure. Its editors offered this bleak assessment: “Nobody really knows how much is wasted. In the United States, a conservative estimate is U.S. $60 billion to $75 billion dollars every year. Just how many ventures fail outright—meaning that they’re either canceled partway through or abandoned shortly after completion—is controversial. For large projects, it’s probably in the 15 to 20 percent range.”154 These grim assessments undermine any claim that taking engineering as a model for software production has been the most effective way to address its problems. Conclusion: Software Crisis or Gender Crisis? This chapter has traced a historical shift in programming methods from a largely forgotten period where women played a major innovative role to a more recent era that saw the rise of engineering as a metaphor and a shrinking role for women. Arguably, one reason for software engineering’s limited success is related to that masculinizing trend. Some of the most intractable problems have arisen because the aspects of software production that rely on stereotypically feminine skills of communication and personal interaction have been devalued and neglected. This can be seen most dramatically in the area of requirements analysis and specification—the initial stages of building software. Requirements analysis had been fairly straightforward in the early days of scientific programming. Often the user was also the programmer, or the user could specify with mathematical precision what was required. But when the bulk of programming shifted from science to business applications, designers had to contend with the messy complexity of the human world, from deciphering arcane bureaucratic procedures to anticipating how ordinary nontechnical users would interact with a system. Software engineers have long been aware that their most serious problems stem from failing to understand what the customer really wants

110  Chapter 3

and needs or from failing to translate these human requirements into appropriate technical requirements for the system.155 Mistakes at this stage can be disastrous, resulting in systems that are technically functional but fail to do what the user wants and that must be rewritten at great expense or, in the worst case, scrapped altogether. Getting the requirements right requires above all an ability to communicate with clients and understand their needs, constraints, and preferred ways of doing business. Yet a number of experts have faulted software engineering for failing to teach and reward those “soft” skills. According to a 1990 study in Communications of the ACM, “a number of authors suggest that [the] overly technical, rational, and economic value orientation of systems designers, accompanied by a lack of attention to political, organizational, and psychological issues, is the cause of deficiencies.”156 The authors warn that the bias toward technical values in software engineering “represents a pathology which needs to be addressed,” and they suggest changes in education and professional codes of ethics “to increase the awareness of the designers of the organizational and human consequences of their designs.”157 A paper presented at a 2000 international conference on The Future of Software Engineering noted that as late as the 1990s, the concepts that “analysis cannot be performed adequately in isolation from the organisational and social context” and that requirements should describe “stakeholders’ goals” were considered “radical new ideas.”158 They urged software engineers to acquire “the social skills to interact with a variety of stakeholders” and suggested that in addition to learning computer science they should study cognitive psychology, anthropology, sociology, linguistics, and philosophy.159 A 1998 article in the British Computer Society’s Computer Journal declared that “We contend that software engineering exhibits symptoms of breakdown, with an acceptance amongst leading advocates that it has failed to deliver.”160 Focusing on “the problem of requirements,” they criticized widely used techniques for being narrowly technical and rigid and argued that engineering culture tends to devalue users’ expertise—“Where users . . . disagree with the ‘rational’ solution, this is not seen as an aspect of contextually situated knowledge to be taken into account, but as an ‘irrational’ response, which can therefore be ignored”—and they conclude that “The crucial issue here is one of communication.”161

Software Crisis or Identity Crisis?   111

The interpersonal skills and liberal arts disciplines that these critics describe as vital have received far less attention in software engineering curricula than the “harder” quantitative techniques of formal specification or programming methodologies. For example, the Software Engineering 2004 undergraduate curriculum developed jointly by IEEE and ACM devotes just 17 out of 494 hours (3 percent) to human interaction skills.162 Even this was too much for some reviewers of the proposed curriculum. Dino Mandrioli, who coauthored Fundamentals of Software Engineering, wrote, “I agree that there are important ‘non technical’ skills, such as communications skills. . . . I also acknowledge that such skills are often lacking in most students and even in various professionals and therefore something has to be done to fill up this hole.” Yet he questioned whether “such skills can and should be taught and learned in a university” and recommended “simply emphasizing the relevance of such issues in 2 hours.”163 One wonders where he imagined aspiring software engineers would acquire these elusive skills. The fact that the requirements problem remains unsolved despite repeated prescriptions for better communication with customers, combined with the evidence that software engineering programs remain firmly technical with little attention to humanities or social sciences, suggest an underlying resistance to investing resources and reputation in these lower-status “feminine” areas. The early history of programming methods shows how seemingly technical debates can encode social issues such as labor and gender. The assumption that programming would be improved by making it more like engineering was based on the cultural linking of engineering with masculinity and, by extension, with prestige and authority. Rethinking the gendered value system that is embedded in the metaphor of engineering—perhaps by reclaiming women’s understandings of the term—has the potential not only to make computer science and programming more appealing to women but also to benefit the discipline itself.164

4 Female Entrepreneurs: Reimagining Software as a Business

Work, its social organisation and rewards are organised for the (stereotype of the) male lifestyle. A support service to handle personal and domestic activities is assumed. . . . Whilst other professions allow a woman to pause in her career [to have children] and re-enter an interrupted career path, this is not possible in the computer industry. The rate of technological and methodological change is too great. It is therefore necessary if one wishes to have a career in this industry, either to opt out of child rearing—which many women do from choice or necessity—or to reduce the work commitment. —Stephanie Shirley, 19811

Work-family balance is a much-debated problem in the early twenty-first century, posing difficult choices for both women and men. But in the midtwentieth century, female programmers such as Stephanie Shirley faced the more fundamental issue of whether it was even possible—or socially acceptable—to combine what had long been considered separate spheres. If they had children, their careers often ran up against what legal scholar Joan Williams has dubbed “the maternal wall,” a combination of biased attitudes and inflexible work structures that block women’s professional advancement.2 This chapter draws on the lives of female software entrepreneurs to illustrate both the problems that working mothers faced in the 1960s and 1970s and the innovative strategies that they employed to surmount them. Two remarkable women independently hit on the idea of starting a freelance programming business—at a time when the software services industry barely existed. Elsie Shutt founded Computations, Inc. in Harvard, Massachusetts, in 1957. Shirley established Freelance Programmers Ltd (later F International) in Hemel Hempstead near London in 1962. Although conditions for women were not identical in the United States

114  Chapter 4

and Great Britain, Shutt and Shirley faced remarkably similar cultural and legal hurdles. Neither went into business primarily to make money, since—as was typical for white, middle-class women of the time—their husbands were expected to provide the main financial support for the family. Instead, they saw freelance work as a way to solve the dilemma of how to embrace parenthood without sacrificing their professional identity and expertise. These enterprises were unusual not simply because they were run by women but because Shutt and Shirley were imagining —and putting into practice—bold changes in the culture of software production. Women’s entrepreneurship in the early computer industry is just beginning to be explored by historians such as Jeffrey R. Yost.3 This chapter surveys the social obstacles and economic opportunities that created the context for Shirley’s and Shutt’s ventures and then describes the innovative business philosophies and strategies these women devised to combat discrimination and make the most of their comparative advantages. Their day-to-day struggles to be taken seriously as both mothers and professionals illustrate how the barriers to reorganizing the workplace to accommodate parents have been ideological as much as technical or economic. They also remind us that gender roles and professional identities are not natural expressions of a given social position but are performances that must be constantly maintained. The final section considers women’s current status in the software services industry and ways that the historical case studies can inform our understanding of women’s continuing struggle to pursue both career and family. Combining Career and Family: An Enduring Dilemma Women entering the computing workforce from World War II through the 1970s faced discrimination—most of it perfectly legal—on the basis of their actual or potential status as mothers. Starting in the nineteenth century, protective legislation limited women’s work hours and conditions because of their assumed physical weakness and childbearing role. In the United Kingdom, a series of national laws collectively referred as Factories Acts were passed beginning in 1802. Among other things, these laws limited women’s work hours and barred them from certain occupations such as coal mining. In the United States, a patchwork of state laws,

Female Entrepreneurs  115

beginning with Wisconsin in 1867, imposed similar restrictions. Such laws often banned night work for women, limited the amount of weight they could be asked to carry, and barred them from working for some period before and after childbirth. This well-meant legislation brought women some relief from grueling workloads and took an important first step toward making the workplace more humane for both sexes. But the laws had consequences far beyond their original intent and constrained the employment options of women who lived many generations later and worked under very different conditions. For computer programmers, who often had to work late hours to gain access to the machines, limits on night work were untenable. A box of printer paper might exceed the amount of weight that a woman could legally carry. The pregnancy bar made little sense for women who were in good health and were engaged in intellectual rather than manual labor. Firsthand accounts by programmers who bore children during the 1950s and 1960s illustrate the challenges that they faced maintaining a career. Some simply stopped working altogether until their children were in school, which sidestepped the problem of finding childcare or parttime work but often made it difficult to reenter such a fast-changing field. Of those who wanted to keep their skills current, most found it hard to find regular part-time programming work. Several were able to freelance sporadically for former employers, former clients, or their husbands, but this brought in a fairly small amount of work (usually averaging much less than half time) and depended on having personal contacts in the industry. Mary Lee (Woods) Berners-Lee exemplifies the improvised nature of many women’s careers after having a baby. She began programming at the UK computer manufacturer Ferranti in 1951 and married software developer Conway Berners-Lee in 1954. After the first of their four children was born a year later, she felt the need to keep working to maintain her professional identity: “It’s a tremendous shock, having been professional, to be at home as a mum; and it’s nice to go into the adult world occasionally.”4 She was also aware that in programming, “if you take a break to have a baby, you can find yourself out of date.” Berners-Lee was able to arrange some sporadic freelance work through her own and her husband’s work contacts: “If somebody had a nice, neat little project, I could program at home and then go to a computer somewhere to test it.

116  Chapter 4

That was good fun!” But she felt such options were rare for women. Another British programmer, Bobby Hersom, took a job at computer manufacturer Elliott Brothers in 1953 and married a coworker in 1954. When the couple started a family, Hersom stopped working, noting both practical and social obstacles: “It was pretty uncommon to be able to leave your child anywhere—to have child-minders—not to mention frowned upon!”5 Like Berners-Lee, she was able to keep active in the field through occasional freelancing for her former employer and through her husband, first by helping informally with his programming problems and then by freelancing on projects that he was working on. Laurie Keller, who held a series of programming jobs in California in the late 1960s, recalled that in the United States, “The barrier of marriage had only just disappeared by ‘68, but having a child was the normal death-knell of a career.  .  . . In virtually all of my early job interviews, about the first thing I was asked, as a young married woman, was when I intended to start a family.”6 Structural aspects of the workplace, such as insurance policies, made it extremely difficult to combine work and childrearing unless an individual could make special ad hoc arrangements with a supportive supervisor. In the mid-1960s, Lois Haibt (one of the original FORTRAN developers) was working sixty hours a week on an important virtual memory project for IBM when she became pregnant. She was not ready to return to this grueling full-time schedule when her three months of maternity leave were up, so her boss, who valued Haibt’s talents, suggested an unusual alternative: “The manager of the group at the time observed that since we had a terminal-oriented system, maybe I could put a terminal at home— which was long before any such things ever happened. So I got a terminal at home and worked part-time.”7 According to Haibt, this arrangement was unprecedented at IBM: “In fact, when they proposed this and it got up to the director of research, who was a corporate vice president at that time, reporting directly to the chairman of the board—when he decided this was a good idea, he’d like to make it happen, it still took five months or something to get the approvals through [IBM headquarters at] Armonk. . . . There were some bureaucrat types who were afraid that I might fall down the cellar steps and sue IBM for workman’s compensation, or who knows what.” Haibt’s experience demonstrates how women could sometimes leverage their highly valued technical expertise to win concessions from employers.

Female Entrepreneurs  117

Judy Clapp, who was working for the MITRE Corporation on the SAGE air defense system in 1965, described a workplace that was structured to accommodate men’s personal commitments but not women’s: “At that time, they had a rule that pregnant women could not work. .  .  . So I said, ‘Okay, I want to take a leave.’ And they said, ‘Sorry, we only give leaves for personal reasons.’ I said, ‘Can you think of anything more personal than being pregnant?’ And they said, ‘No, we have things like a death in the family or having to help out in the family business or something; we don’t have pregnancy in here.’”8 Clapp had no choice but to leave, but her managers at MITRE soon discovered they had made a mistake: Clapp was an essential part of the SAGE development team. They agreed to hire her back as a consultant at a high hourly rate, and as Clapp recalled, “I made more money in two weeks than I’d ever made in my life! At the end of two weeks, they said, ‘We’re reconsidering your being a consultant. . . . We think we’re going to change the rules. It’s okay, you can work.’ . . . In those days that was a huge concession—that they were going to let me come back after.” To her knowledge, she was the first woman at MITRE to come back to work after having a baby, and she set a precedent for allowing others to do the same. Haibt and Clapp were able to continue working not because their employers had unusually progressive policies but because they were considered valuable enough to merit special concessions. The managerial resistance that they encountered (as well as the obstructionist role of the insurance industry) vividly demonstrates how incompatible the notions of motherhood and professionalism were in corporate culture. And even though both Haibt and Clapp managed to shift their employer’s culture toward a more flexible stance, their situations were still precarious. IBM had no provision for permanent part-time employees, so when Haibt’s contracts ran out after three years, she was out of work. Only when her daughter entered school was she able to take another full-time job at IBM. Clapp struggled to cobble together a roster of babysitters (since organized daycare was not available) and would have had difficulty continuing to work had she not had the rare good fortune that her husband, also in computing, was able to work at home. The fact that these exceptional women had to fight even to be allowed to combine professional and family life—let alone achieve “balance” between the two—underscores the near impossibility of this feat for many of their peers.9

118  Chapter 4

Eventually, a series of national laws mandated equality in employment, including the U.S. Equal Pay Act (1963), Title VII of the U.S. Civil Rights Act (1964), the UK Equal Pay Acts (1970 and 1975), and the UK Sex Discrimination Act (1975). These laws alleviated some of the more egregious discriminatory behavior, such as firing pregnant women. The introduction of the birth control pill (approved in the United States in 1960 and offered by the British National Health Service in 1961) also made it easier for women to choose whether and when to have children. But the structure of the workplace and deeply engrained assumptions about what defined a valuable employee continued to create formidable obstacles for women who sought to balance work and family responsibilities. Professional norms were (and to a large extent still are) based on a late-industrial gendered division of labor in which middle-class men were expected to work full-time for a “family wage” while their wives handled the household responsibilities. This social arrangement made it possible for employers to define the ideal worker—the worker who would be preferentially hired, promoted, and rewarded—as someone who could work full-time at the work site.10 This ideal was not gender neutral, since it required that the worker have a mate at home—implicitly a wife—to provide for their physical and social needs as well as care for any children.11 Professional women with families suffered from this definition of gender roles and workplace ideals in three ways. First, the “ideal worker” role was unrealistic for anyone, male or female, who had to balance work with any other significant commitments. Anyone trying to combine a demanding job with child rearing was thus set up for failure. Second, one of the obvious solutions—part-time work—was stigmatized, since employers have tended to equate a desire for part-time work with a lack of commitment.12 As noted above, part-time programming jobs were scarce during the 1950s and 1960s, and the few that existed carried none of the security or benefits of full-time work. Third, mothers were not taken seriously as professionals because the image of motherhood was culturally at odds with the image of the ideal worker and because the two roles were defined as binary, gendered opposites. Mothers were expected to be nurturing rather than competitive (a valued trait in the workplace) and completely absorbed with their children rather than engaged in mentally challenging activities. As Amy J. Cuddy, Susan T. Fiske, and Peter Glick have observed more recently, “Women operate under pressure from

Female Entrepreneurs  119

ambient stereotypes saying that mothers can’t be serious professionals.”13 Because of this dissonance, working mothers have been devalued beyond any objective justification based on their effort or performance.14 Shutt and Shirley were aware that the people around them were likely to see the categories of mother and computer professional as mutually exclusive. Faced with an array of laws, social attitudes, and work practices that made it nearly impossible to accommodate family responsibilities within the traditional workplace, they came up with a more radical solution. Rather than quit, they decided to start their own companies, where they might have the freedom to reinvent both the notion of professionalism and the organization of work. The Rise of the Software Services Industry: New Opportunities I had this idea, first, that software was much more important than anybody else seemed to realize, much more important than hardware—much more interesting, as well. . . . But anyone that claims, “We knew how wonderful the industry was going to be,” I think they’re telling a great big fib. It was just so exciting we didn’t look further than the current project. . . . When you’re young, everything you do is new, and so it wasn’t until afterwards that I realized that some of the things that we were doing were not just new to me but were new, full stop. —Stephanie Shirley, 200115

Before the mid-1960s, there was no such thing as a software industry selling standard, off-the-shelf applications. Instead, organizations that used computers had three main sources of software—their own programming staffs, outside contractors, and free software provided by computer manufacturers. IBM and most of its smaller competitors “bundled” software and programming support services along with its hardware, similar to the way that personal computers and their operating systems are sold as a single package today. Most large businesses also hired their own programming staffs to produce software for their specific needs. Some of these businesses pooled their resources by having their programmers participate in user groups such as SHARE and GUIDE (for IBM users) and USE (for UNIVAC), which distributed programs that members had written and collaboratively developed new ones.16 But many companies, especially smaller businesses, could not afford a dedicated programming staff or simply preferred to outsource their software development. To meet this demand, a software contracting

120  Chapter 4

industry—also known as custom programming or programming services—arose in the mid-1950s. These new companies contracted with government or industry clients to produce one-of-a-kind programs that were tailored to the client’s specific needs. The rapid expansion of computer use in the 1950s and 1960s created a promising market for such contractors. When the first of these firms was established in the United States in 1955, there were only 240 computers in use nationwide. By the time that Elsie Shutt started her company in 1957, there were 1,260 computers, and by 1965 there were 21,600.17 Britain saw similar growth, from only 13 computers in 1955 to 1,582 in 1965.18 The organization of work in contract programming firms reflected the state of computer technology. Until the development of time sharing and minicomputers in the mid-1960s, computers were large, scarce, and expensive, and they had to be shared among many users. Therefore, programmers were not normally able to develop software on the machine itself. Instead, their typical process was to write out the code on paper, have the program transferred to punch cards (typically by a low-paid female keypunch operator), wait for a turn at the computer so that they (or a computer operator) could run the program, and collect the output. The programmer would then pore over the printout looking for bugs before repeating the entire cycle. Since programmers spent only a limited amount of time working interactively with the machine, it was possible for a software contracting firm to operate without its own computer, which meant that startup costs could be low. Most small firms either used the client’s computer or rented computer time from a computer service bureau. Contract programmers usually worked either from the firm’s office or at the client’s site. Although there was nothing in the technology itself that ruled out part-time or home-based programming, very few firms seem to have made room in their business model for either option.19 The software services industry included individuals who did freelance work for their former employers, small businesses with a handful of programmers, and very large corporations.20 In the United States, the early industry was dominated by the Systems Development Corporation (SDC), which was created in 1956 to handle the enormous software development responsibility for the SAGE air defense system. SDC employed 700 programmers—estimated to be half of the U.S. programming workforce at the time—including many women.21 Other large software providers

Female Entrepreneurs  121

included defense contractors such as MITRE and TRW.22 Most software contractors started out much smaller, however. Martin Campbell-Kelly estimates that “about 40 startups—typically with six or fewer programmers—entered the new business of software contracting in the second half of the 1950s.”23 Some of the earliest U.S. firms included Computer Usage Company (CUC) (1955), Corporation for Economic Industrial Research (CEIR) (ca. 1958), Computer Sciences Corporation (CSC) (1959), and Applied Data Research (1959). In the United Kingdom, there were no huge defense contracts comparable to the SAGE project, but small contracting firms existed by 1959 and included Vaughan Systems and Programming Ltd (1959), Computer Analysts and Programmers Ltd (CAP) (1962), Computer Machinery Group (1964), Hoskyns Group (1964), and Logica (1969). Some of the early startups were run by programmers who did the work themselves. Other founders, such as those of CUC, were technically trained but preferred to be managers, and they hired other programmers to do the actual coding. A handful of these companies—including CUC, CSC, CAP, and Logica—grew to have multiple offices (sometimes extending internationally), hundreds of employees, and billions of dollars in revenues.24 But small firms remained the rule in both countries. A study of the U.S. industry in 1968 found that “the vast majority of the more than 1,000 firms in the industry had annual revenue of less than $1 million and a single office.”25 Campbell-Kelly estimates that there were between “several dozen” and eighty software companies in 1974: “most of the software firms were quite small, with a few tens of employees at most.”26 Typically, these modest businesses found clients through personal acquaintances and word-of-mouth recommendations from satisfied customers rather than through marketing. This was an industry where size was not decisive, and with luck and good management, a small firm could continue profitably throughout its founder’s working life. Elsie Shutt and Stephanie Shirley were early entrants into the industry. Shutt appears to have been the first woman to start a software business in the United States, and Shirley was probably the second in England, following Dina Vaughan.27 Vaughan began her programming career at Elliott Brothers in 1955, where she met her husband, Andrew St. Johnston. In 1959, she left Elliott’s to start Vaughan Systems and Programming Ltd, continuing to program for Elliott’s as a freelance subcontractor and

122  Chapter 4

working out of her home under her maiden name. Vaughan steadily grew the business, and in 1960, she was able to hire other programmers and rent office space. In 1968, her husband left Elliott’s to become a partner in the business, and they shifted their focus to creating integrated systems such as automated warehouses and airline flight information systems. By 1979, the company had thirty-three employees.28 Dina Vaughan was undoubtedly a pioneer, but her business model had more in common with her male peers’ models than with Shutt’s and Shirley’s. Like most other contracting startups, her business was a full-time job. It quickly moved out of her home and into an office, and it had no special focus on employing women. Shutt and Shirley took a different path. The industry that these women entered was a tough one. Although barriers to entry were low, running a successful software services business was not trivial. It was crucial for the software entrepreneur to have a high level of technical skill, especially in the early years when most applications were scientific.29 In theory, intellectual capital was all that was needed to start a business, but in practice, firms that lacked access to financial capital had a hard time managing cash flow. The founders of Vaughan complained that “a computer program is not looked on by the Bank Manager as a tangible asset . . . and it takes a very special Bank Manager to advance money on brains and sales ability!”30 Some entrepreneurs, like the partners in Vaughan, mortgaged their personal property to raise funds; others borrowed money from family members. Shirley described the stress involved in running a company without adequate funding: “Without capital behind me, without commercial experience, I recall the risk—the stomach-aching risk—of taking on somebody for six weeks in a summer vacation when we hadn’t got any work for them. And saying, ‘I will get work for them; this person has super skills’—and really thinking, ‘What am I going to do if we haven’t got work for them?’ Because we hadn’t got any savings; there was no money behind the company.” Because the industry was new, the management of software contracts was not well understood, bringing another set of hazards. Each custom software project was, by definition, unique—a new program that might have to run on recently released computer hardware or use an unfamiliar programming language. This made it difficult to estimate labor costs accurately. Firms bid for contracts on either a time-and-materials or a fixedprice basis, and as Campbell-Kelly points out, “The profits on software

Female Entrepreneurs  123

contracting were surprisingly low, typically less than 15 percent of sales, so cost-estimation and project-management skills were essential. Accurate cost estimation was needed to prepare a price-competitive bid, and project-management skills were needed to ensure completion within time and cost constraints.”31 In addition to managing individual projects, firms needed to control the overall flow of work to keep their programmers employed (a concern vividly illustrated by Shirley’s comment above). Projects varied in size and duration, and there was no guarantee when the next contract would arrive. Many startups pursued diversification as a strategy to increase and stabilize their income, but as historian Jeffrey Yost points out, this was a double-edged sword: diversifying too widely strained both the programmers’ ability to learn new machines, languages, and applications and management’s ability to bid for and oversee projects.32 The early history of software services is littered with firms that expanded too fast and perished. Thus, the industry that Shirley and Shutt chose to enter offered both great opportunities and great risks. Origins of Computations, Inc. and F International The excitement of designing a system: . . . finding out what the problem is; analyzing it; designing something that will make it work; and then doing it. And seeing it work, and having a client who’s happy with it. That’s very satisfying. —Elsie Shutt, 200133

Born in 1928 in Baltimore, Maryland, Elsie Shutt graduated from Goucher College and learned to program at a summer job at the U.S. Army’s Aberdeen Proving Ground in Maryland, where she used the ORDVAC (Ordnance Discrete Variable Automatic Computer), one of ENIAC’s successors (figure 4.1). Talented in math, she won a graduate fellowship to Radcliffe College and studied in France on a Fulbright scholarship. She married soon after and took time off from graduate school to work. Her old boss from Aberdeen, Dick Clippinger, was now at Raytheon Company in Waltham, Massachusetts, and he hired her as a programmer in 1953. Clippinger’s group was in charge of producing software for a computer that was under development—the Raycom (later Datamatic 1000). But because the hardware development was going slowly, the group had

124  Chapter 4

Figure 4.1 Elsie Shutt in 1963. Source: “Mixing Math and Motherhood,” Business Week, March 2, 1963, 86.

time to take on programming jobs for outside clients. When Shutt became pregnant in 1957, state law required her to quit the job she loved, but she wanted to remain professionally active. Fortunately, her pregnancy coincided with Raytheon’s decision to cut back on its outside programming projects, which left a vacuum that Shutt could fill. A client for whom she had worked wanted additional programming done, and Raytheon referred them to Shutt, who had stopped working but not yet had her baby. She continued to do freelance work for a year or so in collaboration with her friend Irma Wyman, and with Clippinger’s encouragement the two contemplated starting their own company. Events finally pushed Shutt to take that step: “I was doing some work for Honeywell, and I needed help; it was more than I could do by myself.” She decided to recruit two colleagues who were also in her situation—new mothers who wanted to keep programming: “I had a baby.

Female Entrepreneurs  125

Elaine Kamowitz, in the meantime, also had a baby—she had been working full-time there—and Barbara Wade had a baby, too. And I said [to Honeywell], ‘If you subcontract to me, and to Elaine, and to Barbara, the three of us could work on it.’ And they couldn’t do it; it was too much subcontracting. So that’s why we incorporated. I incorporated and hired them.” She named the new company Computations, Inc. Shutt’s unconventional workforce—new mothers who worked parttime—became the basis of a successful business model. The firm offered programming services and also systems analysis and design for both scientific and business applications.34 She chose to keep the company small and never employed more than thirteen staff members. Running her own company allowed her to maintain the intellectual challenge of designing software and the satisfaction of meeting clients’ needs without sacrificing her family life: “It was wonderful for me because I wanted to be home with my children when they were young, and I was. So in the summer, there’d be swimming lessons at the beach, and I’d go sit on the beach with the children and come home and have supper and get them ready for bed and go in to the computer.” Although her initial decision to incorporate had been based on short-term expediency, it had the effect of adding some permanence to what might otherwise have been a one-time arrangement. In fact, forty-five years later, Comp Inc. was still in business with Shutt at the helm. Stephanie Shirley was born in 1933 in Germany to Jewish parents. When she was five, she and her sister were evacuated to England as part of the kindertransport that rescued many Jewish children, and they were adopted by a British couple. (Shirley’s parents survived the Holocaust, but the family was not reunited until later.) In 1951, Shirley took a job at the mathematics laboratory of the Post Office Research Station at Dollis Hill, London. Because her foster parents could not afford to send her to college, she decided to earn a mathematics degree from the University of London through evening classes. One day, a classmate took her to see the computer facility where he worked, and she immediately became interested in learning to program. Eventually, she had the chance to work on several important projects for the Post Office, including helping to design special-purpose computers for the first electronic telephone exchanges. In 1959, she married her coworker Derek Shirley, a physicist. Feeling that it would be awkward to continue working in the same place as

126  Chapter 4

her husband, she took a job at Computer Developments Limited (CDL), a joint subsidiary of manufacturers GEC Computers and International Computers and Tabulators (ICT). She worked there for eighteen months in both a technical and managerial capacity, leading a team responsible for testing the new 1301 computer.35 Like Shutt, Shirley soon became focused on the issue of combining work with childrearing. She and her husband were planning a family, and when they did have a son—soon after she started her company—the ability to work from home became important (figure 4.2). But her immediate motivation to start her own business was a series of discriminatory experiences. The first jolt came at the Post Office. In 1956, she earned her honors college degree, a milestone that normally made employees eligible for promotion: “I applied for promotion to my boss—said, ‘I want to go on for the next grade’—and it caused quite a lot of fuss because they’d never had a woman at the grade that I was applying for.” The British civil service handled promotions through a panel that interviewed and evaluated candidates. According to Shirley, “Rumors got around to me that my panel kept resigning, the ones that were going to interview me; for some of them had got enough integrity to admit, ‘I would never appoint a woman. There’s no point in me sitting on this panel. I won’t appoint any woman.’”36 Whatever the closed-door discussions were, Shirley never received her promotion. When she left the Post Office for the commercial sector a few years later, she was pleasantly surprised to receive a large salary increase. But at CDL, she eventually hit a glass ceiling once again: “I was making suggestions at management meetings and so on—marketing-oriented suggestions—and was told explicitly, ‘Keep quiet. It has nothing to do with you. You’re technical.’” It seemed evident to her that CDL was not going to allow her to participate in business activities that led to the management track: “I went home, thought about it very carefully, came back, and resigned the next day. I saw, even in this excellent company, very good, I was not going to get anywhere.” Shirley concluded that the way to get ahead was to become her own boss. She started Freelance Programmers Ltd in 1962, with herself as the sole employee. Like Shutt, she soon began to recruit other women who wanted to work part-time while raising children, and by 1964, her company had a regular “panel” of home-based female programmers.37 Unlike

Female Entrepreneurs  127

Figure 4.2 Stephanie Shirley and son Giles in 1963. Photo courtesy of Dame Stephanie Shirley.

Shutt, Shirley had ambitions to see her company grow. By the mid-1960s, she had 65 workers, and by 1984, there was a roster of 750, with about three-quarters of them employed at any given time.38 She renamed the company F International (FI) in 1971.39 (This name is used in most historical sources and is used in the remainder of this chapter.) Shirley was proud of heading one of the most successful software services companies in Britain, but she eventually decided that it was time to move on. In 1985, she recruited Hilary Cropper, an ambitious manager who had hit her own glass ceiling at International Computers Limited (ICL), to take over leadership of FI. Between 1985 and 2002, Cropper helped increase the company’s revenues from £7 million to £450 million and “twice topped the table of Britain’s highest-paid businesswomen.”40 Shirley retired from the company in 1993 after having made a fortune but continued to be active in in charitable, educational, and government projects and also in business as an independent director of various companies. For her contributions to the British software industry, she was made Dame Commander of the Order of the British Empire in 2000.

128  Chapter 4

Business Visions: Rethinking the Gendered Workplace What it turned into was a feeling of mission in providing work for women who were talented and did good work and couldn’t get part-time jobs. Because you couldn’t get them. . . . That sort of inspired us to try to do this thing. —Elsie Shutt, 2001

Shirley and Shutt did more than succeed as female entrepreneurs in a man’s world; they also radically rethought what a business could be. They challenged the business culture that refused to take mothers or part-time workers seriously, and they even questioned the fundamental purpose of running a commercial enterprise. The fact that these two women developed such similar visions—even though they worked in different countries and were unknown to each other until many years later—speaks to the common problems that were faced by women who tried to maintain professional careers as mothers. One important innovation was that Comp Inc. and FI seem to have been the only software businesses in either country that relied entirely on part-time, home-based workers. A second was that—in a reversal of ordinary business practice—they preferentially hired mothers of young children. Third, both businesses soon developed an explicit social mission of providing rewarding technical work for at-home mothers; profit was secondary. “I didn’t have any ambitions, particularly, to be a wheelerdealer,” Shutt said. “The important thing became having work available for women—and not to supplement their incomes so much as to make it possible to stay up to date in a rapidly changing field, so that when the children were grown and left, you could go back to a career.” Although she acknowledged that “it helped a lot to have extra income,” she felt the main benefit was to keep active in the field and experience the intellectual stimulation that programming provided. The company also provided women who had no programming experience the opportunity to enter this promising career track—at a time when women with no formal technical training and with family obligations that did not allow them to work full-time had few options to find well-paying and stimulating work. Shutt employed a few men over the years, but most of the programmers (and all of the partners) at Comp Inc. were women.41 Shirley also saw her business not as a source of profit but as a means for women to stay active in the technical world: “It was certainly not

Female Entrepreneurs  129

intended, was not targeted, to make serious money. My husband had a modest but perfectly adequate job, and a safe job also, in civil service. I even investigated running it as a charity.” She contrasted her approach with that of Dina Vaughan, the other female pioneer of software services in Britain: “I went to see her, and she was very helpful in talking about the business, but I came away horrified. . . . Because she talked entirely in terms of figures and measures and numbers. And for me, the numbers are important—they have to be done—but they are not the purpose or the be-all of the business. They are almost a necessary evil, and of course, that makes me very ‘uncommercial’ by most commercial people’s standards.” As Shirley began to recruit other programmers, providing meaningful work for at-home mothers grew to be the central focus of her company: “It was a crusade—somebody called it a crusade, and that’s about right. . . . It became much more focused on women—opportunities for women to go on working in a professional level—and that was more important than the technology, more important than the money side.” Initially, FI hired only women with children and prioritized work assignments based on social need: “High priority was women who were the breadwinners, unmarried mothers—again, rather different in those days and not as accepted as they are today—and people with severe disabilities. Then there were women with children, but there was a breadwinner in the background. .  .  . And then women without children, perhaps pregnant.” FI became known among female British programmers as one of their few options for part-time employment.42 Through their business models, Shutt and Shirley challenged contemporary assumptions about both women and business and advanced two radical alternatives—that mothers were a workforce to be taken seriously and that social change was a legitimate goal for entrepreneurship. As FI grew and gained public visibility, Shirley also saw her company as providing a role model of women who were able to excel in the technical and business arenas. She nurtured women as leaders, promoting them from within, and felt an obligation to represent her sex with distinction. Failure was not an option, since it would confirm people’s doubts about women’s business ability: “When the ’70s recession came, my pride was at stake, and the crusade for women as professional workers in this or any other industry was very much at stake. I was absolutely determined that we were not going to be a fair-weather company that was fine as long as their market was easy and [then] collapsed. So we hung in there.”

130  Chapter 4

As Shirley’s comment illustrates, financial success may not have been the highest goal of this business model, but it was a necessary means, and Shutt and Shirley faced many challenges in achieving it. Their choice to employ dispersed, part-time workers forced them to develop novel management techniques. As women, they also had to overcome sexism, which required creative image management. The following sections consider how Shutt and Shirley met these demands. Management Challenges and Innovations Contemporary observers agreed that running a software services company in the early years of the industry was a daunting task, especially since management techniques for programming were in their infancy. Although the computer industry as a whole found much to complain about in the 1960s (as detailed in chapter 3), the problems of contract programmers seemed particularly acute. Herbert Robinson of CEIR described software services in 1963 as “a completely new area of technology where there was no fund of experience, no signposts, nothing to indicate the wisdom of the policy decisions that had to be made.”43 The head of another early software services company, John F. Keane, described the dire consequences of a lack of explicit management principles: “I went on vacation and came back in August 1971. And within I would say less than four weeks, there were five projects that were well over budget.”44 CSC president Fletcher Jones maintained that “the technical talent shortage and the groping of management for a direction is characteristic of a new industry practicing frontiersmanship.”45 Shutt and Shirley faced unique project-management challenges as a consequence of their business model. In contrast to the typical enterprise with full-time staff members who shared an office, Shutt and Shirley had to divide programming projects among a large, fluctuating workforce of parttime programmers, and they had to find ways to coordinate teams that were physically dispersed. As Shirley noted, even something as simple as recognizing one’s fellow employees could not be taken for granted: “We had a whole lot of women, each working very remotely, communicating almost entirely by post and phone. We wore little badges so we would recognize each other when we had to actually turn up with a client!” Both women managed to overcome these challenges and even turn them to advantage.

Female Entrepreneurs  131

On the technical side, Shutt and Shirley had to learn to conceptualize a program as a set of modular units so that they could divide a large project among many dispersed workers. Shutt’s approach was to organize her programmers in teams that collaboratively divided the work among themselves: “We would get together every week, everybody working on the project. One thing we had to learn to do was to take a job and to break it into pieces—meaningful pieces—and then we’d get together, talk about it, assign jobs.” She coached her programmers to be meticulous, which resulted in efficiencies for the company and a better product for the client. For example, she emphasized desk-checking, the practice of having programmers review each other’s code before running it on the computer. Although desk-checking was a fairly common practice in the 1950s, Shutt believed that she “emphasized it more than others did” because “we were doing things that we broke up into more pieces than some people did.” Comp Inc. had no room for “egotistical” programmers who refused the share their code.46 Another key priority was “documenting it—well—so that someone else would be able to maintain it if they needed to.” Producing modular, well-documented code also made it easier for Comp Inc. to repurpose programs for subsequent clients, which saved on programming costs. Shirley developed her own techniques for managing programmers. She was fortunate that her first contract in 1962, for the Urwick-Diebold management consultancy, involved her in developing methods for managing programmers:47 “They wanted a set of standards to be developed for their computer service, before the first person was even appointed. That was a very valuable introduction, to actually have the opportunity to be paid to work on such standards; and we were commissioned to update them later on, also. Of course, they became the basis of our own standards.” In 1964, Shirley hired a Urwick-Diebold consultant to advise her on business issues such as cash flow. This early investment in management training paid off, helping her avoid the fate of many other companies that grew faster than their financial structures could accommodate.48 One of Shirley’s strategic decisions was to favor fixed-price contracts. As CEIR’s Robinson noted, choosing the right price for such contracts was difficult, but he asserted, “The successful companies of the future will be those using fixed price who have developed much better techniques for defining the problem and estimating the cost of the job, and who also employ sound contract administration as the job progresses.”49 Shirley

132  Chapter 4

was one of the few who developed such organizational discipline, and she credited much of her success to this: “Our way of operation forced us into an assessment of work content. It forced us into a strict work regime. It forced us into measuring work done and payment by work done so that we could offer customers fixed-priced, fixed-delivery.”50 Shirley achieved through careful management of human resources some of the productivity improvements that software engineering had promised: “Being forced to do that . . . actually led us to become a prime mover in the promotion of software, because we could really manage software—and everybody else said it was unmanageable.” She also learned from her failures. In 1967, one of FI’s projects was jeopardized when the assigned programmer failed to make progress after several weeks. In desperation, Shirley “left her husband looking after the baby and went and sat in on the contract, working between sixteen and twenty hours a day. She had to learn FORTRAN. . . . In one week and two weekends she got the job working.”51 Shirley recalled, “When we survived that one, we really put in a whole lot of safeguards and standards. . . . We eventually developed a ‘cookbook’ philosophy: anyone joining the company had very little induction face-to-face, but they had a great big cookbook that told them how to write a letter, how to respond to this, how to do that, how to get their stuff checked, and so on.” The pitfalls of managing a remote staff forced Shirley to invest in better workplace procedures and communication. In addition to honing their project-management skills, Shutt and Shirley brought in business by offering high-quality work for low prices. One of Comp Inc.’s clients claimed they had saved as much as 50 percent by outsourcing to Shutt’s company.52 Working at home kept overhead costs low, as did the fact that workers at both companies did not receive any benefits besides salary and in some cases waited to be paid until after the contract was completed. To keep themselves competitive, both FI and Comp Inc. invested in ongoing training for their programmers, hoping to anticipate rather than follow the market. Shirley recalled how difficult it was to predict the impact of new developments such as the COBOL language, created in 1959: “We took the risk of training a hundred people in COBOL before we got our first COBOL assignment.” In contrast, a survey of the UK software industry conducted several years later found

Female Entrepreneurs  133

that in general, “The U.K. software industry invests very little in training. It is reported to be ‘pitifully low’ by international standards.”53 A willingness to learn new skills became crucial during the technical and economic upheavals of the 1970s. The U.S. recession that began in 1969 hit the computer industry hard in 1970. Computer sales dried up, stock prices tumbled, industry leader IBM cut its programming staff, and many small companies went bankrupt. By 1971, it was estimated that half of the software and services firms of the boom years had gone out of business, and one industry source claimed that 15 percent of U.S. programmers were seeking work.54 As Campbell-Kelly observes, “it was a baptism by fire for largely unseasoned managements that had known only good times.”55 This was followed by the 1973 energy crisis that put both the U.S. and UK economies into recession and limited growth in the software contracting industry for much of the decade. At the same time, new programming languages and a shift in the market from scientific to business applications were changing the market for services. Many firms went under, but Shutt was able to ride out the storm with some creative risk taking. As she later recalled, “Elaine and I thought of just stopping entirely. We didn’t have any work.” She added that the market was moving away from the scientific programming that she was familiar with and toward business applications using COBOL: “We didn’t know beans about COBOL! But we’d always said, ‘We will program in any language.’” She decided to cold-call Data General, knowing that the computer manufacturer did not have any in-house customer-support programmers: “They said that they would tell their clients about us, and sure enough, they mentioned us to Dean Junior College. . . . That was our first business application. The way we got that was to bid quite low. . . . That got us started again.” Shutt used this low-paid job as a COBOL training opportunity that paved the way for more profitable contracts. For Shirley, the management discipline that she had developed in earlier years helped her turn a loss in 1971 into a profit in 1972, despite a substantial reduction in business.56 Perhaps the greatest testament to Shirley’s management ability was that another firm was willing to pay to learn her methods. In 1978, FI made an arrangement that allowed the U.S. firm Heights Information Technology Systems to license FI’s business methods, including work practices, model business forms, management techniques,

134  Chapter 4

and recruitment and training. Heights then established branches in New York and California, adopting Shirley’s part-time freelance model.57 There was one aspect of business in which Comp Inc. and FI actually had a competitive advantage—recruiting women. As noted earlier, gender-biased laws and corporate policies meant that many traditional firms lost skilled female programmers who wanted to continue working after having a child. Shirley found that she was easily able to recruit experienced programmers by word of mouth: “What I was doing was so strange that I’d get a radio interview or something for thirty seconds, and then there’d be a flood of correspondence coming in from women who also wanted to work—because there was nothing available parttime, home-based, for women doing technical work.” She recalled that IBM was an unintentional source of trained staff for FI: “For many years, IBM would not employ part-time systems engineers. So when some of their good systems engineers—the women—married and wanted to go on to part-time for whatever reason, they had to leave—and they came to us, beautifully trained!” These displaced workers were also a source of intelligence about IBM’s management strategies, which Shirley selectively copied (for example, its emphasis on training). Shutt described gaining both employees and contracts when other companies laid off new mothers. For example, she hired a woman who had worked at Raytheon and wanted to continue working after her child was born: “She did the same Raytheon work that she had done before, but on our payroll.” Another advantage for Shutt, as a 1980 professional newsletter reported, was that she had an “unusually stable” workforce in a field where worker mobility was high. This saved Shutt the trouble of training new workers and also was a selling point with her customers. Anyone who contracted out a software project ran the risk that when the program needed updates in the future, the original programmers would have long since left the employ of the contractor. Comp Inc.’s programmers were less likely than their male peers to move or take a full-time job at another company, so clients could be reassured that “the same programmer is often available for enhancement or maintenance on her past projects.”58 Other female entrepreneurs had similar experiences. For example, Grace Gentry and her husband, Richard, incorporated as a software services firm in California in 1974. The first contract programmers that they hired were women that Grace Gentry knew from a previous

Female Entrepreneurs  135

job and who, as married women, appreciated the potential flexibility of contract work and were less concerned than their male peers with job security, benefits, and promotion.59 An episode in which Shirley encountered unexpected difficulties in recruiting women is a reminder that gendered expectations and opportunities for workers are culturally specific. In 1973, FI hired a new chair, Frank Knight, and he and Shirley moved to expand FI into Europe. They decided to start with Denmark, realizing only belatedly that because of different social policies, Denmark did not have the captive female workforce that Great Britain (and the United States) did. “Denmark’s greatest attraction was the relatively high proportion of women in the data-processing industry,” recounted a business text describing FI’s failed strategy, but “What [Shirley] and Frank Knight had failed to spot was that the main reason for the high proportion of women in the Danish data processing industry was the fact that Denmark had evolved over the years a much more sophisticated child-care system than had Britain.”60 Danish women evidently did not need part-time work while raising children, and FI was unable to recruit an adequate number of programmers. Shirley’s firm ended up hiring Danish systems analysts to do the initial work of setting up jobs and then sent the bulk of the programming work back to women in Britain, who were grateful for the opportunity to work that their Danish counterparts took for granted. This example shows how social support structures can broaden the cultural notion of the ideal technical worker so that having a family is not automatically defined as a “problem” that the worker must solve on her own. Constructing a New Image: Mothers as Working Professionals I think everyone was laughing at me! But not to my face. The press were very kind to me, and I asked a journalist many years later why they hadn’t knocked me. He replied, “We saw you as a source of good stories, and didn’t want to kill the goose that laid the golden eggs.” It was laughable! —Stephanie Shirley, 2001

For many Americans and Britons in the 1960s, the categories of “serious technical professional” and “good wife and mother” had no overlap. The occasional media coverage that Comp Inc. and FI received often treated the idea of a business run by women—especially mothers—as a joke. Shutt

136  Chapter 4

recalled, “We were called ‘the pregnant programmers.’ That was because of [a 1963] Business Week article that coined that phrase.” Shutt benefited from the coverage in terms of recruiting employees, but she complained that the article, titled “Mixing Math and Motherhood,” overemphasized the oddity of housewives being professionals. It featured a contrived photo of a “typical scene” with a female programmer working at a desk in the background and an unattended baby prominently displayed in the foreground61 (figure 4.3). The somewhat defensive quotations from Shutt in the article suggest that she was struggling to be taken seriously by the reporter: “‘Hiring housewives is not a gimmick,’ says Mrs. Shutt,” and “Mrs. Shutt emphasizes . . . that Computations Inc. is not to be considered a feminist diversion.”62 Shutt was probably right to be suspicious. Would a Business Week article about a male entrepreneur have emphasized his parental status as much as his business achievements? Shirley also felt that the media patronized her as a female entrepreneur. For example, she was mentioned in a 1964 article in the Guardian on “Computer Women.” Although she was grateful for the publicity, which helped recruit workers to her business, the image conveyed was not of a serious businesswoman but of a “retired” mother doing a bit of programming on the side: “Now retired, with a young baby, she has found that computer programming . . . is a job that can be done at home between feeding the baby and washing nappies.”63 Shirley complained that other headlines referred to FI’s programmers as “her girls” and made “all sorts of gender jokes, some quite sexist.” A direct consequence of this stereotyping may have been a loss of potential business for the two firms, although this is difficult to verify. Reflecting on this possibility in a 2001 interview, Shutt caught herself articulating the same cultural bias that sees women (especially mothers) as trivial and unprofessional: “I have a feeling that there may have been people who wouldn’t have wanted us to do the work because they thought maybe we would trivialize—that we would not be able to do it because we were just women, or we would be working at home and taking care of children at the same time, and therefore it would not be professional.” She added that such people “obviously didn’t hire us.” To counteract the negative stereotypes of women in business, Shutt and Shirley were driven to expend considerable effort on managing their personal images—a “tax” on their business energies that male competitors did not have to pay. Paradoxically, they

Female Entrepreneurs  137

Figure 4.3 A staged photo purporting to show a “typical scene in home of one of CI’s ‘pregnant programmers.’” Source: “Mixing Math and Motherhood,” Business Week, March 2, 1963, 86.

138  Chapter 4

were called on both to disguise their gender to avoid appearing “unprofessional” and to perform the feminine role to avoid appearing “unnatural.” The most dramatic example of disguise was Shirley’s decision to adopt a masculine name: “My name is Stephanie, and in the first year or so I was writing business development letters, trying to get appointments to see people, and getting next to no response. My husband suggested that I abbreviate my name to Steve, and this I did. And it seemed to me that I got a better response—was through that door and facing somebody before people realized my gender! And I’ve been Steve ever since.” Both women also took pains to hide the fact that they and their associates were taking care of children in addition to programming. Shutt described how she hired a babysitter to come to her house every Wednesday, “so that if someone called and said, ‘Can you come in? I have a job,’ I’d say, ‘I can come in on Wednesday.’ I wouldn’t have to say, ‘I’ll see if I can arrange a baby sitter.’” Shirley even used sound effects to make her home seem more like a conventional workplace: “I had a tape of somebody typing [that I played] in the background, so that when I was on the phone, it would sound as if I’d got an office behind me!” She expected her programmers to hide their maternal status as well, recalling that at one client meeting for a large project, “I turned around and apparently glared at somebody coming through the door with a toddler in a pushchair! Luckily it was a civil servant, the client. I would not allow any sign of domesticity to appear because we were very vulnerable.” Shirley’s efforts at image management even affected the way that she priced contracts. As noted earlier, she preferred fixed-price contracts. These had some obvious business advantages—they provided a predictable income, and they were often preferred by customers who were wary of escalating costs—but Shirley also saw a more subtle benefit: they allowed her to avoid making explicit charges for labor time.64 In this way, she could divert the client’s attention from her unorthodox workforce, “so that the clients were not really told how the work was done; they knew how it was done, but it was not stressed in any way.” Shirley hoped to neutralize “the dislike of the customers . . . to think of their work being done in this cottage industry sort of way. . . . And women! ‘Goodness gracious, these housewives! What’re they going to do?’” Shirley’s desire to make her programmers invisible contrasted starkly with male-run firms’ freedom to capitalize on their workers’ identities.

Female Entrepreneurs  139

Campbell-Kelly notes that “Firms often touted their ‘star’ creative employees (in this case, programmers)” and cites an advertisement for CSC that listed an all-male roster of “well-known professionals.”65 To ensure that her own employees would not be dismissed as “housewives”—who were stereotypically assumed to lack expertise—Shirley followed a strategy she described as “overqualification.” She made sure that both she and her employees had impressive formal credentials: “I think we overqualified. We made sure that our people had a qualification to offer. Many of them came in with B.Sc.s or Ph.D.s,” she recalled. “When counseling women in that era, I would always say, ‘Get that qualification!’ Certainly I did. I mean, nobody could say I was not qualified to do a job.” Yet even as they were fighting to maintain their professional status, Shirley and Shutt felt contradictory demands to satisfy cultural expectations for “feminine” (and heteronormative) appearance and behavior. Shirley in particular described the difficulty of toeing an invisible line between being seen as either a “sex object” or “butch.” On the one hand, “We were very, very prim and proper, so as not to be seen as sex objects. We never talked about it, but you knew very well that women were not expected to operate at that level. You were somebody to be laughed at, somebody to be flirted with, somebody whose bottom you could pinch. I defy you to sell a major project to somebody who is pinching your bottom!” Yet she also felt the need to dispel what one contemporary journalist referred to as “the notion that female programmers are dull, drab, lipstickless creatures.”66 Shirley recalled, “We didn’t allow trousers for a long, long time because we didn’t want to be seen as ‘pseudo-men.’” Looking back from 2001, she seemed surprised to realize the extent of the image-management work that she had taken for granted in the 1960s as simply the price of trying to be a female professional: “It was a quite an effort—now that I think about it, how much effort we put into it without realizing it—to make sure that we were seen as professional, that people didn’t giggle when we came in through the door.” A woman who was successful in business also ran the danger of being sneered at as a deficient wife and mother, as Shirley found out in a painfully public way: “Somebody did a study of dual career families and wrote about me—and it was under my name, it wasn’t anonymous—using a phrase which I can quote now: ‘Like many women of her ilk, she is indifferent to the appearance of her home.’ And I was devastated! I’m very

140  Chapter 4

far from indifferent; I just think there are other things more important.” Compounding the problem, a middle-class woman who worked outside the home might find her husband stigmatized as an inadequate provider. Although neither Shutt nor Shirley felt the pressure of having to support her family financially, Shirley in particular faced the opposite dilemma of needing to appear professional and yet not too successful: “It was very difficult to make sure that my husband was not denigrated because I was working. People would say—including my mother, for example—‘Oh! I thought Derek had a good job.’ And one really had to be very careful to keep that balance. For a long time, I struggled to keep my own earnings below my husband’s—because there was just the sheer macho image that the man was not only the father, the man was the leader of the family, and women were very much secondary citizens.” In short, the female software entrepreneur had to manage not only technical and business challenges but also the difficult balancing act of presenting herself as feminine but not too feminine, professional but not too professional. Both Shirley and Shutt emphasized how essential it was that they had their husbands’ full support—emotionally, financially, and domestically in sharing household chores and childcare. Outcomes There have been people who have gotten started in the field thanks to us, and that’s a nice feeling. There are people who have had much more creative and meaningful things to do than they would have otherwise, and that’s a nice feeling. And we still enjoy the work. —Elsie Shutt, 2001

As software entrepreneurs, Elsie Shutt and “Steve” Shirley chose to innovate their way around discrimination by inventing new corporate models and work practices. They consciously reimagined programming work as compatible with family responsibilities, working mothers as technical experts to be taken seriously, and corporations as vehicles for social change. FI and Comp Inc. made a difference in the lives of many individual women, offering them the opportunity to continue (or begin) a satisfying career in programming. Both companies also received media coverage that gave their approaches wider exposure. Noted feminist Betty Friedan mentioned Shutt in a 1964 article as an example of a woman who had successfully moved beyond the “feminine mystique” to create

Female Entrepreneurs  141

a “four-dimensional career.”67 Shirley became a visible role model as FI grew in size, and she would eventually be elected the first female president of the British Computer Society in 1989. The firms’ later histories, however, reveal how difficult it was to resist the larger technical and social factors that were shaping work practices in the software industry. Comp Inc. stayed much the same in its organization, but as time went on, the work was more often located at the client’s site rather than in the worker’s home, giving programmers less flexibility to balance work and family. Asked in 2001 whether part-time work had become more common in the computer industry, Shutt felt that there was still resistance: “I think it’s more common now—but it’s still not as common as it should be. And they still balk at shared jobs, which I think would be a very good thing to do.” FI underwent more far-reaching changes after Hilary Cropper took over its leadership in 1985. In some ways, she maintained the company’s commitment to supporting work-family balance. For example, she instituted an unusual flexible benefits program that allowed employees to make tradeoffs between pay and vacation time to suit their lifestyles. But in other ways, the company became more like the mainstream software industry, discarding Shirley’s model of providing work for home-based mothers. As Cropper acknowledged in 2000, “the original company espoused working from home, which nobody does now.”68 She also made a point of hiring men. The FI of the twenty-first century is still unusual in its family-friendly policies, worker empowerment, and large percentage of women in highlevel positions. Whether it still provides a radical alternative for women (or men) who want to be both programmers and parents is less clear. Many women continue to make careers in freelance programming. Off-the-shelf software products were introduced in 1965 and by the twenty-first century had become a hundred-billion-dollar global industry, but contrary to some predictions, they did not make custom programming obsolete. In 1997, programming services generated 42 percent of revenues for the U.S. software industry, compared to only 36 percent for packaged software products.69 In 2002, an estimated 177,000 firms were providing programming services in the United States, and roughly 32,000 of these companies, or 18 percent, were headed by women.70 Although it is doubtful that these women know of Shutt’s and Shirley’s trailblazing work, some of their entrepreneurial efforts are probably motivated by a similar desire for work-family balance.

142  Chapter 4

Shirley and Shutt proved that a successful business could be organized around workers’ family commitments. But has the software industry embraced this broadened concept of technical professionalism, or does the child-free, “ideal worker” still reign? The days when programmers were obliged to quit their jobs on the arrival of a baby are long gone. But structural obstacles, such as employers’ reluctance to allow part-time professional work and a lack of childcare options, still make it difficult in practice for women to keep working after having a baby or for men to take on a larger share of their children’s care.71 Part of this reluctance to change, I argue, is because the popular image of a serious professional still evokes a full-time worker who keeps his or her domestic and business worlds completely separate. A review of recent research shows how mothers and part-time workers continue to be unfairly stigmatized, to the detriment of both workers and the larger society. A set of controlled studies by Shelley J. Correll, Stephen Benard, and In Paik found that prospective employers discriminated among equally qualified professional women on the basis of motherhood. When job applicants were identified as mothers, they were judged to be less competent (not just less available or committed) than when the same women were labeled as nonmothers. The authors conclude that “the ‘motherhood penalty’ on wages and evaluations of workplace performance and suitability occurs, at least partially, because cultural understandings of the motherhood role exist in tension with the cultural understandings of the ‘ideal worker’ role.” They emphasize that it is the images, rather than the reality, that are incompatible: “While it has often been observed that ‘face time’ and long hours are not necessarily associated with actual worker performance or productivity, in the contemporary organization of work, they function as a cultural sign of the effort component of performance capacity.”72 Legal scholars Joan C. Williams and Holly Cohen Cooper argue that changing the bias against parents is a key—and achievable—policy for promoting workplace equity. As they point out, “The linkage of devotion to family with economic marginalization is socially constructed; it could be deconstructed, by redefining the ideal worker to reflect the typical life patterns of adults with ongoing responsibilities for family care.”73 Other data indicate a lingering distrust of part-time and at-home work arrangements, which both reflects and reinforces gender bias. Observing

Female Entrepreneurs  143

that 90 percent of part-time workers in the United Kingdom were women, a 1981 study by Erika Szyszczak hypothesized that part-time work was devalued precisely because women were more likely to seek it.74 Conversely, Cecilia L. Ridgeway and Shelley J. Correll argue that “Normative cultural beliefs about mothers’ lesser work commitments are probably only sustainable because of cultural attitudes towards part-time work patterns.”75 Home-based work has also been viewed with suspicion, as managers fear a loss of control when employees work out of their sight. Jack Nilles, the researcher who coined the term telecommuting in 1973, was disappointed to report in 1996 that “Many managers feel dependent on eyeball contact with their employees as a prerequisite for effective supervision.”76 As with part-time work, the distrust of telecommuting may encode gender bias. In a 2004 study by Amy J. C. Cuddy, Susan T. Fiske, and Peter Glick—one of several in which workers identified as mothers were rated lower than identically qualified nonmothers—participants claimed that they had given the women lower marks because they were described as telecommuters, not because they were mothers. Noting that the nonmothers in the study had also been described as telecommuters and had not been penalized, the researchers concluded that “the telecommuting provided an ideal excuse for discrimination against the working mom.”77 The treatment of part-time workers is an area in which the United States and the United Kingdom (as a member of the European Union) may now be diverging. EU Council Directive 97/81/EC of December 15, 1997, directs member states “to provide for the removal of discrimination against part-time workers and to improve the quality of part-time work,” specifying that “part-time workers shall not be treated in a less favourable manner than comparable full-time workers solely because they work part time.”78 This may herald a shift in workplace culture, but the changes have not been immediate. A 1999 study of UK information technology workers reported that “The lack of part-time scheme could be a serious hurdle to women’s retention in the IT industry,” noting that women sometimes left senior technical jobs when part-time work was not available after a maternity leave. The study concluded, “The IT industry has therefore an obligation not only to innovate in product development but also in work and organizational arrangements.”79 Yet these innovations had already been made by Shutt and Shirley thirty-five years earlier. The question is not whether they can work, but why they have not been more widely adopted.

5 Gender in Academic Computing: Alternative Career Paths and Norms

The end of the twentieth century witnessed a worldwide trend toward the greater participation of women in science and engineering, and in higher education overall. The only major discipline that bucked this global trend was computing. —Women and Information Technology: Research on Underrepresentation, 20061

Despite a long history of female accomplishment in computing, women’s participation in academic computer science remains low and may even be declining. Women’s share of U.S. computer science bachelor’s degrees increased from 15 percent in 1966 to a peak of 37 percent in 1984, but these promising gains did not last: by 2008, the share of degrees earned by women fell to 18 percent2 (figure 5.1). At the master’s degree level, the proportion of women peaked in 2000 at 33 percent and fell to 27 percent by 2008. The percentage of women earning Ph.D.s in computer science has not fallen but remains low, at only 22 percent in 2008.3 Long-term data for the United Kingdom are less available, but recent figures paint a picture that is similar to the U.S. situation, with women receiving 18 percent of undergraduate and 20 percent of postgraduate degrees in computer science in 2010.4 Computer science has one of the lowest proportions of female Ph.D.s of any science, and no other field of science or engineering has shown a net decline in the proportion of women earning bachelor’s degrees since the mid-1980s.5 For faculty, only 17 percent were female at U.S. Ph.D.-granting computer science departments in 2009, and 22 percent were female at UK units in “computer software engineering” or “information technology and systems sciences” in 2004.6 Women are hired at top universities at a

146  Chapter 5

60 CS All S&E

50

Percentage

40

30

20

2008

2006

2004

2002

2000

1998

1996

1994

1992

1990

1988

1986

1984

1982

1980

1978

1976

1974

1972

1970

1969

0

1966

10

Year

Figure 5.1 Percentage of bachelor’s degrees awarded to women: Computer science compared with all science and engineering, 1966 to 2006. Source: Data from National Science Foundation, Science and Engineering Degrees, 1966–2006 (NSF 08-321), ed. Susan T. Hill and Jean M. Johnson (Arlington, VA: NSF, 2004), tables 3 and 34. Data for 1999 were not available.

much lower rate than their representation in recent Ph.D.s, and they end up disproportionately concentrated in less prestigious community colleges and polytechnics or in insecure adjunct positions.7 Does underrepresentation necessarily imply injustice? One thing is certain: it does not stem from women’s lack of merit. J. McGrath Cohoon and William Aspray’s 2006 review of the most rigorous research to date concludes that women’s underrepresentation in computing cannot be attributed to their lesser “academic fitness” or personal characteristics such as a lack of competitive drive.8 Rather, qualified women seem to be choosing not to go into computer science. But if women’s absence from academic computing is voluntary, why is it a problem? This raises the question of what constitutes a meaningful choice. Surrounded by exaggerated stereotypes about antisocial male nerds, young women may feel that pursuing computer science is incompatible with being an attractive, feminine, or sociable person.9 An even bigger barrier may be the fear that

Gender in Academic Computing   147

choosing a computer science career means sacrificing family life, since the typical computer science department provides few if any role models of women who successfully balance work and family.10 These are not choices that most men are forced to make. Women who do decide to study computer science face other challenges, discussed below, that make them more likely than men to leave the field. And the loss is great—both for the women who are deprived of the rewards of this intellectual pursuit and for the nations that could benefit from their talents.11 This chapter begins with a brief overview of the rise of computer science as an academic discipline, which is followed by a survey of the literature on women in computing that identifies some of the major barriers they have faced. But rather than viewing women as victims, the remainder of the chapter highlights some of the creative strategies that they have adopted to overcome these obstacles and to challenge stereotypes that favor men. The first set of examples shows how women who had been denied the chance to earn traditional academic credentials were nonetheless able to secure jobs as computer science faculty. The second section focuses on women’s involvement in professional societies such as the Association for Computing Machinery (ACM). These societies have provided an environment where women can meet female peers and build professional networks. They also have helped some women gain the visibility and credentials to climb the academic career ladder, especially when their home departments were not supportive. A third strategy has been for women to create their own technical organizations and events. Female-centered professional groups have addressed issues of isolation and discrimination directly, building a sense of community and facilitating career mentoring between senior and junior academics. Collectively, these activities have created new support networks for women, new possibilities for recognition and authority, new chances to define the intellectual content of the field, new opportunities to shape its pedagogy, and—most radically—a chance to reimagine the social norms of computer science in a less masculine way. The Rise of Academic Computer Science Computer science encompasses far more than computer programming, although this often provides a student’s first exposure to the field. Computer science includes a substantial body of theory in areas ranging from

148  Chapter 5

numerical methods to the nature of intelligence. University researchers initially focused on designing and constructing their own computers, but as the private sector took over production, their attention shifted to exploring the theoretical side of computing. The term computer science is attributed to Louis Fein, a consultant who wrote a widely read 1959 report on the state of computing education in U.S. universities. For Fein, “the computer sciences” encompassed “simulators, computers, automation, language translation, switching theory, information theory, coding theory, cybernetics, decision theory, statistics, operations research, econometrics, psychometrics, management science, linear programming, game theory, automata theory, artificial intelligence, self-organizing machines, adaptive mechanisms, neural psychology, learning machines, and numerical analyses.”12 This expansive list suggests the difficulty of pinning down a discipline whose underlying technologies were changing rapidly and whose applications were encroaching on most of the traditional arts and sciences. Over the years, computer scientists have variously defined their field as the study of computing machines, software tools, problem-solving processes (algorithms), information, various applications, or some combination of these.13 Some of the uncertainty over the nature of computer science stems from the haphazard manner in which it emerged. Computer science as an academic discipline arose fairly quickly in both the United States and United Kingdom and became firmly established within twenty years. Immediately after World War II, the schools that built the first computers— the University of Pennsylvania, Harvard University, the Massachusetts Institute of Technology, and Cambridge University—began offering seminars and hands-on classes to share knowledge about the new technology with researchers and advanced students.14 With financial support from government and industry, other universities adopted the computer as a research tool and then recruited computing experts (or potential experts) to help their faculty use the machine.15 Theory raced to catch up with practice, and computer science as a discipline emerged as an afterthought. In a typical sequence, a computer was introduced as a service center, and a few seminars and graduate courses were offered. Gradually, some faculty developed research programs around computing and added more courses, and eventually, there would be enough courses to offer degrees in computing within an existing department such as math or engineering. In some cases, the computing group eventually established its own separate

Gender in Academic Computing   149

department. The first faculty came to academic computer science through various routes: some were hired to run computer centers; some moved over from existing engineering or math departments; some were drawn in from other disciplines that used computers heavily, such as linguistics or chemistry; and some were recruited from industry. By the early 1960s, universities in the United Kingdom were offering undergraduate degrees that combined computer science with another field, most commonly mathematics. The first bachelor’s degree solely in computing in Britain was offered in 1964.16 In the United States, ACM reported in 1965 that there were “at least 17 colleges” offering undergraduate degrees in computer science, “more than 20” with master’s, and “more than 15” with doctoral programs.17 By 1966, Robert W. Rector, a candidate for ACM president, could assert, “I agree with many that the battle for recognition of the computer sciences as a discipline has been won.”18 After steady growth throughout the 1970s, the number of students majoring in computer science shot upward in the 1980s, when personal computers became widely available. From 1980 to 1985, the number of bachelor’s degrees awarded in computer science in the United States more than tripled, from 11,213 to 39,121.19 Women played an active part in this vigorous growth, earning more than a third of undergraduate computer science degrees in 1985. So why have their numbers fallen in the decades since? Gender and Participation in Academic Computer Science Since the early 1990s, when a decline in women’s participation in both computer science degrees and programming jobs became evident, researchers and concerned practitioners have spent considerable energy trying to explain this troubling trend.20 Most scholars conclude that there are multiple causes. The problem begins as early as childhood, when girls are socialized to avoid stereotypically masculine activities and boys are allowed to dominate computer classes, labs, and clubs in grade school. Young women may feel put off by the popular image of the computer geek—an obsessive, antisocial, hygienically challenged male—and excluded from the largely masculine subculture of computer gaming.21 Women tend to arrive at college with less computing experience than their male peers, which reinforces the perception that they are less adept at computer science than men, and they often lack peer support.

150  Chapter 5

As college students flocked to computer science in the 1980s, departments tried to cut down the numbers to a manageable size. Many schools instituted entry requirements that favored candidates with precollege computer experience. Mandatory first-year courses with daunting workloads became a favored mechanism to weed out students with less ability—but also discouraged many others who simply had less experience or confidence. As a result of these measures, fewer women than men have been admitted to computer science programs, and a higher percentage drop out. Although the gendered effects of these changes were probably unintentional—many programs that imposed these requirements also actively recruited women—they are also unsurprising. An illuminating study by Carnegie Mellon University, home to a top computer science department, shows how academic standards of merit can arbitrarily favor men. CMU had been giving priority in admissions to applicants with programming experience, who were far more likely to be male. But when a committee studied the issue, they discovered that prior programming activity did not predict academic performance in any significant way. Behaviors typical of males, such as joining a computer club or getting a programming job in high school, were simply assumed to indicate excellence.22 Graduate computer science departments can also be unwelcoming for women. Although the blatantly sexist behavior described in Ellen Spertus’s 1991 study “Why Are There So Few Female Computer Scientists?” has diminished, more recent studies report that female doctoral students get less respect, mentoring, and help with research, grants, and publications than their male peers.23 In a 2007 report on the status of women scientists at American universities, Donna Nelson argued that many female Ph.D.s have been so alienated during their graduate school years that they refuse to apply for academic posts at research universities.24 Women who pursue an academic career face pressure to do research and publish to gain tenure, and the tenure clock overlaps the period of life when many women wish to begin a family. Accommodations for work-family balance, such as part-time work or stopping the tenure clock for childbirth, are recent introductions and not always offered. Female computer scientists often suffer from a lack of mentors who can pass on the unwritten rules for gaining resources and status in a particular field or institution. Computer scientists Maria Klawe and Nancy Leveson described in 1995 how women have faced “exclusion from important, informal ‘clubs’ and networks; and difficulty in establishing

Gender in Academic Computing   151

funding,” in part because they lacked mentors who would connect them with influential people at funding agencies.25 In addition, as Abigail Stewart points out in a 2007 report, “Many smart motivated women have cited isolation and marginalization as reasons for moving out of science and engineering at major research institutions.”26 Isolation is not simply a matter of social discomfort: successful scientific careers depend on collaboration, information sharing, and visibility within the peer group that will validate one’s competence and authority. Many marks of status in science are bestowed at least partly on the basis of name recognition, so that those who are already famous tend to get a disproportionate amount of credit and those who are perceived as outsiders get less than their share.27 Klawe and Leveson note that women in computer science do just as well as men when judged by blind peer review but that bias creeps in when the identity (and thus gender) of the person is known. Women “are not always equally represented in the more subjectively selected positions in our field, such as program committee members, distinguished lecturers, invited and keynote speakers, colloquium speakers, and editorial board members,” and as a consequence, “women often have less visibility than the quality of their research warrants.”28 The research summarized here deals in generalities. Numerous women have found their departments to be supportive or have preferred to work independently and forge their own networks. But those who have felt isolated, unappreciated, or stuck at the bottom have often found creative strategies for changing their fortunes. The following sections describe how some women compensated for early experiences that blocked them from earning traditional academic credentials; coped with work-family conflicts; and overcame a lack of mentoring, peer support, or visibility. In the process, many of them also worked to change the system so that those who followed could find academic computer science more welcoming. Alternative Paths to Success in Academia The nontraditional paths to success that I focus on—entering academic jobs without a Ph.D., using professional societies for support and exposure, and creating professional forums for women—are those that were most frequently mentioned in my interviews and seemed to have most significantly affected women’s lives. The examples span a wide time period, from the founding of ACM in the 1950s with several female charter

152  Chapter 5

members, through the founding of women’s organizations in the 1970s, to the creation of an entire technical conference for women in computing—the Grace Hopper Celebration—in the 1990s. Notably, many of the later developments occurred in the context of the women’s movement. The first computer science departments arose in parallel with a series of feminist milestones, such as Betty Friedan’s The Feminine Mystique (1963), the U.S. Equal Pay Act (1963), Title VII of the U.S. Civil Rights Act (1964), the founding of the National Organization of Women (NOW) (1966), the UK Equal Pay Act (1970), the beginning of Ms. magazine (1971), the passage of the Equal Rights Amendment by both houses of the U.S. Congress (1972) (although the amendment failed to be ratified by the states), and the UK Sex Discrimination Act (1975). The women’s movement led to a surge in women who earned degrees in nontraditional fields, computer science among them.29 Some of the career strategies of women in computer science were informed by feminist theory and politics, and others were not but nonetheless occurred in a context where gender stereotypes were being challenged. Feminism became a resource that was available to women who wanted to transform and not just survive the culture of academic computing. I do not claim that these examples represent typical experiences or approaches that were taken by women in computer science, nor that women’s actions were always part of a conscious strategy to overcome gender bias. Indeed, a recurring theme in women’s accounts was the improvised nature of their careers. What these examples reveal is how the professional structures and practices of computer science reflected—but could also be used to change—a male-oriented computing culture. These stories also make clear that women often had to put in extra work to earn the same level of opportunity and recognition as their male peers. Women’s accounts illustrate, at the level of personal experience, how individuals were able to carve out paths to success, locating the space for agency in lives constrained by gender roles. Nontraditional Qualifications: Professors without Ph.D.s My first degree was English language and literature, and one of the questions I was constantly being asked was, “How can you possibly be teaching computer science in higher education without having a computer science degree?” —Laurie Keller, 200130

Gender in Academic Computing   153

In the early decades of computing, the growing demand for computer staff at universities and the short supply of people with computer science degrees or experience created openings for people without traditional academic qualifications. For women who had never been encouraged to pursue a technical major or a higher degree, this created an unusual second chance to enter the academic “pipeline”—a metaphor that is itself based on the masculine model of an uninterrupted linear progression from secondary school to college, graduate school, and eventually a faculty job.31 After these women got a foot in the door, the challenge was to move up from a temporary job or lower-tier institution, which historically had been dead ends for many aspiring female academics, to a betterpaying, more respected, and more secure position.32 Women’s narratives reveal the daunting level of hard work and persistence that this move up often required. Ten of the women whom I interviewed obtained academic jobs with only a bachelor’s or master’s degree (three earned Ph.D.s later in their careers).33 Most entered the academic workforce between 1965 and 1979, before the upward surge in computer science degrees, and all but one were working in the United Kingdom, where a much smaller percentage of the population earned postgraduate degrees. An additional enabling factor in the UK was the transformation of its university system during this period. In 1969, the Open University was founded and pioneered home-based higher education using televised lectures. It is now the largest university in the United Kingdom. Its distance-learning model placed a premium on staff members who were fluent with information technology. The two interviewees who entered academia in the 1980s without Ph.D.s, Laurie Keller and Karen Shipp, both worked there. A more momentous change came in 1992, when the government offered Britain’s polytechnics—which had always been decidedly lower in status and resources—the opportunity to become regular universities. Thirty-eight of them did so, almost doubling the number of British universities overnight. For women who had been largely shut out of traditional university faculties and relegated to second-class status at polytechnics, the shake-up of the university system provided some new openings.34 Gillian Lovegrove’s story illustrates both the opportunities that women could grasp by venturing outside the traditional university system and the

154  Chapter 5

challenges of pursuing a demanding job that was structured for workers who did not have childcare concerns. Lovegrove came from an economically modest background but earned a place at Cambridge University, where she received a bachelor’s degree in mathematics. She stayed on to get a diploma (similar to a master of science) in computing in 1965 and took a teaching job at Portsmouth Polytechnic, which offered her an adequate salary but little opportunity for research. Deciding that she needed to improve her academic credentials, Lovegrove enrolled as a doctoral student at nearby Southampton University in 1968. The faculty at Southampton were supportive, and after her first year, they hired her as a lecturer while continuing to give her substantial time to finish her doctoral research on modular operating systems. Before Lovegrove could earn her Ph.D., however, her progress was slowed by the birth of her first child. By the time she completed the degree in 1974, she had two children with a third soon to follow. Recalling that it took her two years to make the final revisions to her thesis, Lovegrove described how discouraging it was to measure her progress against the (implicitly male) norm of the researcher who was not juggling work with childcare: “I kept thinking, ‘Why can’t I do it perfectly the first time?” and ‘Why am I so slow submitting these changes?’—instead of seeing it in the perspective of, ‘This is a fantastic achievement because you’ve got two young, small children at home and even to think about finishing your Ph.D. and focusing on that is something very good!’ I didn’t see it like that. I just saw that I really wasn’t being good enough.”35 Lovegrove continued to teach part-time until 1980. When she resumed full-time work as a lecturer, she was caring for three children between the ages of two and nine; her marriage was under strain; and she was struggling to catch up with nine years of change in computer technology. She later recalled the overwhelming stress of this balancing act: “It was a tremendous struggle keeping going on a daily basis.” When she divorced in 1987, she felt both relief at having a stable home life and “this huge need to prove myself” after years of not being able to do her best work. Lovegrove threw herself into her new research on object-oriented computing, but after fifteen years of struggling to manage a difficult family situation along with her work and not publishing as much as she would have liked, she still had a long march up the traditional promotion path from lecturer to senior lecturer and then professor.

Gender in Academic Computing   155

The newly elevated polytechnics offered a chance to get on a faster track. In 1992, she applied to two of them, aiming at higher positions as head of department, with the prospect of promotion to professor in a few years: “Much to my amazement, both universities were very interested. . . . I’d never realized that I was that attractive to them.” She joined Staffordshire University in 1992 as head of information systems within the School of Computing and then moved to University of Northumbria as head of the School of Computing and Mathematics and eventually dean. As an administrator, Lovegrove felt that her management approach was enhanced by her own experience of struggle. She noted in our 2001 interview, “I’ve now got eighty-odd [people], each of whom I actually care about and want to gain satisfaction from their work position. . . . If they don’t do as well in something, . . . . I will always try and approach it with, ‘Well, we’re in this situation now, so let’s get out of it. How do we do it? And what do we build for the future?’ Because I have been there.” This management style reflects the standpoint of someone who knows what it is like to fall outside narrowly defined standards of merit. Lovegrove leapfrogged into a leadership position by moving from a traditional university to a former polytechnic. Jean Bacon’s career illustrates the opposite strategy—using the polytechnics as a stepping stone to the elite ranks at Cambridge. After getting a B.S. in math from the University of London in 1964, Bacon did programming for the General Electric Company for four years. She enjoyed the work but left in 1968 for what she hoped would be a more family-friendly job at nearby Watford Polytechnic: “I started thinking, ‘Well, I should have a family, maybe, and how to fit it in with working where you get a fortnight’s holiday a year?’ And lecturing seemed an attractive proposition from that point of view.”36 Like Lovegrove, Bacon studied for a postgraduate degree parttime while teaching. She earned her master of science at Hatfield Polytechnic, a larger school nearby, and then took a lectureship at Hatfield in 1973. She gave birth to a son three years later and was fortunate to have on-site daycare provided by the polytechnic. In 1978, Bacon decided to pursue a Ph.D. At this point, she was raising a toddler, working full time as a lecturer, and trying to do doctoral research in whatever time she could spare: “This was very hard in that you didn’t get time off for doing this.” But by the late 1970s, academic computer science had become well established, and Bacon realized she would not be

156  Chapter 5

able to compete without a Ph.D.: “The young had started to move through from doing their degrees, and most of them had Ph.D.s, . . . so I thought I should do a Ph.D. It was an obvious thing to catch up.” She chose to do her doctoral research on distributed operating systems, a hot topic in the early 1980s. Working part-time, Bacon managed to complete her degree in three years, in part by cleverly coordinating her research and teaching: “The way I managed to do it was to get students doing alternative designs. . . . I was trying to look at operating systems and their components but not trying to do it all myself. . . . So at least I got them to concede that I could do more [student] project supervision and less lecturing—and so I managed to do the Ph.D. in that way!” After earning her Ph.D. in 1981, Bacon recalled, she persuaded the department to adopt a policy of giving people time off to work on their Ph.D.s, so that others would not have to struggle the way she had. In 1985, she applied for a position at Cambridge University, which was one of the main centers for research in distributed computing. Bacon became the first women hired at Cambridge as a lecturer in computing and eventually rose to the rank of professor.37 Another way that women with nontraditional backgrounds could get a foot in the academic door was to offer needed technical skills and then work their way into a teaching position. Hilary Kahn earned her B.A. in Latin and Greek in 1965, but finding few jobs in the classics, she went on to get a diploma in computer science from the University of Newcastle and then programmed for one year at English Electric. In 1967, she was able to get a job as assistant lecturer at Manchester University—a major center of computer research—by agreeing to provide some necessary programming support to the computer science department: “It was fundamentally very brave of the department to appoint me because why would they appoint a classicist, with one year in industry, one year postgrad diploma? Part of the reason was, I think, because I said I’d done COBOL. . . . Their theory was that I’d work on compilers, which I didn’t fancy; and their particular theory was I’d write a COBOL compiler—which I truly didn’t fancy.”38 After paying her dues as a COBOL programmer and lecturer for several years, she volunteered for another, more appealing service project—writing a logic simulator for the MU-5 computer that the university was building. From this beginning, Kahn built a long and fruitful research career in computer-aided design and information modeling, and she began bringing in outside grants from the Alvey project and

Gender in Academic Computing   157

the Defense Advanced Research Projects Agency (DARPA). Although she never earned a Ph.D.—university rules prohibited her from supervising Ph.D. students while being a degree candidate herself, and she did not want to give up working with doctoral students—she was nonetheless promoted to professor and later became department chair. Kahn was able to transform herself from unemployed classicist to computer science professor with an unusual level of support in balancing work and family, both from her husband and colleague, computer scientist Brian Napper, and from their department at Manchester. When they had a child, she recalled, her husband proposed to department head Tom Kilburn that both members of the couple reduce their hours and pay by one-third, so that they could take turns with the childcare: “Tom Kilburn said, ‘Well, are you going to be doing two-thirds of a job?’ And we said, ‘No, no, no, we just realized that because of peculiar time-keeping, we could inconvenience people.’ And he said, ‘No, if you’re actually going to do a full job, then you should be paid a full salary.’ . . . So they allowed us to work flexi-hours, long before flexi-hours were invented.” Structural support for academic scientists with family responsibilities—such as guarantees of flexible hours, reduced teaching loads, or extra time on the tenure clock—is a recent innovation and by no means universal. In the absence of such measures, women’s ability to balance family with a computer science career may still depend on being lucky enough to have an understanding spouse or employer. Joyce Currie Little provides an American example of several of these strategies—using her industry experience and badly needed technical skills to get into teaching and earning a Ph.D. while working and raising children. Little earned an M.S. in applied math in 1957 while working as a computer programmer in the aviation industry and then taught computer courses at San Diego State. After accompanying her husband to Maryland in 1963, she was hired as a lecturer in statistics and assistant director of the Academic Computer Center at Goucher College—a job that she got because the college was looking for someone familiar with the IBM 1620, which Little had used at Convair. In 1965, she inquired at nearby Baltimore Junior College to see if she could move into a full-time teaching position. They, too, had just obtained an IBM 1620 and eagerly hired her to set up courses using it. Little grasped the opportunity to establish herself academically: she chaired the computer science department, her program

158  Chapter 5

received an award for outstanding curriculum from the National Science Foundation, and she headed an ACM committee to develop a computer science curriculum for two-year colleges. Little also began working on a Ph.D. in 1974 because she knew that an M.S. was no longer enough to advance in academic computer science: “Several other people at ACM had all said, ‘You know, you really should think about getting your degree. . . . If you want to apply for grants, if you want to do a lot of other activities, that degree is more recognized; and if you ever went into a four-year school, that degree is now getting to be more and more required.’” She had to juggle her doctoral work with the demands of a new baby and a full-time job and did not receive the degree until 1984. In 1981, with her Ph.D. research nearing completion, she was able to get a position at Towson University. She became the first chair of its new computer and information sciences department and later a full professor, with research programs in software engineering, systems analysis and design as well as social and ethical aspects of computing. For these talented and determined women, it was possible to climb from the lower ranks into a secure, research-oriented job at a university—although often only after years of toil in low-status jobs with little time for scholarship. What factors aided them? They sometimes benefited from historical events, such as the transformation of the British university system. A common challenge was balancing work and family, for which women described varying levels of accommodation from employers but little systematic assistance. Finally, their personal stories suggest that encouragement from key individuals—husbands, colleagues, senior administrators—was crucial in helping them overcome the limited expectations that others (or they themselves) had for their success. Homes away from Home: Professional Societies I got much more respect away from Berkeley than here. . . . My peer group was outside; my professional colleagues. . . . Professionally, I think being out in the world like that was very good for me. —Susan Graham, 200239

Several women emphasized their activities in professional computing groups such as the Association for Computing Machinery (ACM), the Institute of Electrical and Electronics Engineers (IEEE) Computer Society, and the British Computer Society (BCS). These organizations perform

Gender in Academic Computing   159

functions that are vital to the discipline: they subsidize and manage the publication of research journals; they organize conferences; they create model curricula; they foster interuniversity and international collaboration; they recognize individual achievement with awards; and they allow computer scientists with similar research interests to form “special interest groups” (U.S.) or “specialist groups” (UK) where they can discuss emerging research areas and build the critical mass to support a journal or conference for the new specialty. Because the societies have always had low barriers to entry and rely on volunteers for most of their activities, anyone who is able and willing to devote the time can participate in significant discipline-building work. The earliest society, the Association for Computing Machinery, was founded in 1947 “to advance the science, development, construction, and application” of computers.40 Most of the founders were young unknowns. One of them, Harry Goheen, recalled that an aim of the society was to lower status barriers between members: “It was founded by a bunch of people who were ‘outs,’ and I think this was intended to influence it so that a young man going to a meeting of the ACM has a chance to meet anybody in the field that’s interested in his kind of work, and talk with him . . . as a man whose ideas are as important as the established practitioner.”41 This openness applied to women as well. The executive council elected at the first meeting included Mina Rees, then head of the Mathematics Branch at the Office of Naval Research, who became the first female president of the American Association for the Advancement of Science in 1971. By May 1948, ACM counted at least 27 women among 459 members, including Rees; Grace Murray Hopper; ENIAC veterans Jean Jennings, Ruth Lichterman, Homè S. MacAllister, and Betty Snyder; and Gertrude Blanch and Ida Rhodes of the National Bureau of Standards.42 The other major U.S. organization, the IEEE Computer Society, arose from the engineering community. The Institute of Electrical and Electronics Engineers (IEEE) was formed in 1963 from the merger of the Institute of Radio Engineers (IRE) and the American Institute of Electrical Engineers (AIEE). The AIEE had formed a computing interest group in 1946, as did the IRE in 1951, and these were combined in 1964 to form the IEEE Computer Society.43 The IEEE Computer Society was less academically oriented than ACM and less involved in curriculum development, but it actively promoted research through professional conferences and journals.

160  Chapter 5

ACM and IEEE grew into international organizations, but the British Computer Society (BCS), founded in 1957, provided a more local venue for bringing together university and industry computer experts. BCS was initially very research oriented; one of its main activities was organizing technical lectures for members to attend. In 1958, BCS began publishing the Computer Journal, featuring technical articles by the EDSAC builders among others, and the first BCS conference was held in Cambridge in June 1959. The society became more industry-oriented in the 1980s and 1990s, although it still retains a strong academic component. Professional societies offered a number of advantages for women. They provided a forum where individuals could gain visibility through public presentations and be judged on their work rather than their institutional affiliation. This gave unknown women from lower-ranked schools or from industry a chance to make their mark and perhaps get a more prestigious academic job. Women could serve on conference program committees, prize committees, editorial boards, and as officers, which gave them real power to shape the field. Society meetings allowed isolated women to meet others in their field and to network with people of both sexes who could offer advice, job leads, or research collaboration. All of this helped women gain the visibility and credentials to climb the academic career ladder. Women’s personal accounts illustrate how professional societies could nurture neophytes who showed promise but had rough edges due to a lack of guidance. For example, Barbara Liskov had studied with the famous artificial intelligence expert John McCarthy at Stanford University and earned her Ph.D. in 1968, but her advisers gave her no assistance in finding a faculty job, and her only offer came from a small college with a heavy teaching load. She ended up taking a job at the MITRE Corporation doing operating systems research, a field she had begun to feel more interested in than artificial intelligence. In 1971, Liskov prepared a paper on her project for the ACM Symposium on Operating System Principles (SOSP). In writing her first major paper, Liskov was fortunate to be mentored by her boss at MITRE, Judy Clapp: “I’d never got any feedback on technical writing. Judy was the only person who ever did that for me. But she really helped me write that paper by reading it and criticizing it. . . . I submitted this paper to the top systems conference, and it got in. . . . And it was a prize-winner in that conference; it was one of the top papers.”44 As a result, Liskov was able to move quickly from industry to a major academic

Gender in Academic Computing   161

department: “I gave my talk, and Jerry Saltzer, who was on the faculty here at MIT, was the chair of that session, and as a result I was asked to apply for a faculty position at MIT.” She was hired in 1972 and eventually rose to an endowed professorship there, receiving the top awards from both IEEE and ACM for her work on programming methodologies. Given her obvious talent, one wonders whether Liskov would have received more mentoring and help with career placement from her male graduate school advisors had she been a man. In any case, with some female mentoring she was able to use a professional conference as an alternate entrance to the academic fast track. Adele Goldberg became active in ACM in 1969 while working on her Ph.D. in information science. She began attending meetings of the Special Interest Group on Computers in Education, where she met one of the members of Alan Kay’s team at Xerox PARC, which was developing the Alto personal computer with a vision of using it for education. Through this connection Goldberg was offered a job at PARC in 1973, where she co-developed the Smalltalk programming language. Goldberg was elected president of ACM in 1984. Anita Borg earned her Ph.D. in 1981 and then worked for several years at a startup called Auragen, where she was one of the main creators of a cutting-edge fault-tolerant operating system. In 1983, she submitted a paper on her work to SOSP—a move that she described as “the best thing that ever happened to my career.”45 Knowing little about academic writing standards, Borg sent in what she later confessed was “really a terrible little paper,” but instead of rejecting it, the conference organizers offered to mentor her: “I got a letter back . . . saying, ‘Well, we see that the ideas are great, but the paper really needs work, so we’re going to give you a shepherd to help you put together a good paper.’” This assistance was all the more remarkable considering that the conference was highly selective, with eighty-three papers submitted to fill only sixteen slots on the program.46 Sensing a rare opportunity, Borg worked hard on her revision and presentation: “I’d never given a paper before; I’d never even given a talk before; and I gave a stunning paper, a stunning talk, to three hundred of the top people in operating systems. Suddenly I was on the map.”47 When her project at Auragen folded two years later, she was easily able to find work at the well-respected research lab of Digital Equipment Corporation (DEC). Borg later used her ACM connections to launch a research institute on women and technology (discussed below).

162  Chapter 5

In addition to showcasing the role of professional societies, the career paths of Liskov, Goldberg, and Borg illustrate another theme that came up in interviews with women: government or industry research labs as a welcoming alternative to academic employment. Adele Goldberg emphasized how supportive Xerox PARC was; for example, they gave her an Alto computer to use at home while she cared for her baby.48 Susan Bond began her research career in 1965 at the mathematics division of the UK Royal Radar Establishment, where she gained recognition for her work on the ALGOL 68 compiler and eventually rose to become Superintendent of Computing and Software Research. She later discovered that the head of her division, Philip Woodward, had been “actively recruiting women” as an affordable source of high-quality researchers: “he was very keen to build up the division in research, and it was difficult for the Civil Service to attract high-quality graduates at the time because of the salary, and he thought women might be a different pool.”49 Fan Chung Graham, who earned her Ph.D. in computer science in 1974, took her first job as a postdoc at Bell Labs, which she described as “a wonderful experience” and added, “I think maybe it was lucky in a way to go to a university much later, after I’d been through the Labs. You are sort of dodging the usual tenure track process, and all that pressure.”50 At the lab she could focus on research without having to teach—a much-needed relief for a mother of two young children—and after a number of years she was able to move back to the University of Pennsylvania as a tenured full professor. Research labs, in conjunction with professional societies, offered some women a chance to maintain their identity as researchers outside the university, allowing them to re-enter the academic world at a more opportune time. The British Computer Society offered women and men who had not been able to pursue a traditional university degree a second chance to earn professional credentials. BCS had an ordinary membership that was open to all, but in 1968, it added a professional membership grade, which a BCS president ambitiously described as “comparable to engineering, accountancy and law.”51 Members could qualify for this grade by earning a college degree, by accruing numerous years of professional experience, or by passing a series of difficult exams. The BCS professional membership gained additional importance in 1985, when the UK Engineering Council delegated to BCS the right to grant chartered engineer status to

Gender in Academic Computing   163

members that it deemed qualified. “Chartered engineer” is an important professional credential in the UK and is sometimes treated as the equivalent of a university degree. Although the BCS certification was probably more important to those working in industry, it offered female academics a way to build their credibility—and in the male-dominated engineering domain. Laurie Keller, who never earned a Ph.D. but became a chartered engineer through the BCS, felt that earning the right to add the initials C.E. to her name not only improved her prospects for promotion at the Open University but also helped counter gender bias: “As a woman, you tend not to be taken quite so seriously, and being able to put the initials after your name says, ‘Yes: I’m somebody to be taken seriously.’” Some women who already had academic jobs found that professional societies gave them opportunities and support that were lacking in their home institutions. Susan Graham (quoted above) felt that her home department at the University of California at Berkeley, which was dominated by engineers, did not value her work in programming language systems or see it as a serious research area. She used ACM as a platform to help promote her field, participating in the Special Interest Group on Programming Languages (SIGPLAN) and serving as the first editor in chief of an important journal on programming languages. For Joyce Currie Little, who had spent many years of her early academic career at a community college, ACM provided different role models: people who had Ph.D.s and encouraged her to get one. One colleague that she met there, Dick Austing, later served on her doctoral committee. Professional societies also broadened the horizons for women in industrial research labs. Jean Sammet, who held programming jobs at Sperry Rand and Sylvania before joining IBM in 1961, noted that professional societies offered a neutral forum where researchers from competing companies could share ideas and industry researchers could talk to their academic counterparts.52 She founded ACM’s Special Interest Group on Symbolic and Algebraic Manipulation (SIGSAM) in 1965 and organized its first symposium in 1966, fostering collaboration among like-minded researchers while raising her own visibility as an important figure in the field. Fellow IBM researcher Fran Allen was also active in ACM and described such outside activities as a way around the corporate glass ceiling: “That’s why I went and did a lot of things outside. I got very involved outside. And that’s a very common thing for women to do. . . . I was supported inside [IBM],

164  Chapter 5

in terms of having big groups to do a lot of nice experimental work, but I knew it wasn’t going to take me anywhere” in terms of becoming a leader in the field.53 Allen became well-known outside of IBM for her research on optimizing compilers, which undoubtedly raised her profile at her home institution: in 1989, she was named the first female IBM fellow, an honor the company bestows on a select few of its top researchers. Unlike most universities or corporations, professional societies offered women a realistic chance of holding the highest offices. Sammet was elected the first female president of ACM in 1974. She was followed by Adele Goldberg in 1984, Gwen Bell in 1992, Barbara Simons in 1998, Maria Klawe in 2002, and Wendy Hall in 2008.54 The IEEE Computer Society did not elect a female president until 1984, when Martha Sloan took office, but subsequently women regularly served in the top office—Helen M. Wood in 1990, Laurel V. Kaleda in 1994, Doris L. Carver in 1998, Guylaine M. Pollock in 2000, Deborah M. Cooper in 2006, and Susan K. (Kathy) Land in 2009.55 Software entrepreneur Stephanie Shirley had been a founding member of BCS in 1957 and became its first female president in 1989, followed by Wendy Hall in 2003, Rachel Burnett in 2007, and Elizabeth Sparrow in 2009.56 The presence of women in the highest positions gave other women confidence that they could participate as equals in professional organizations. As Susan Graham commented, “When I was still quite junior, Jean Sammet was the president of the ACM, and so there didn’t seem to be any barriers at the top for women in that organization.” Professional societies could provide an alternate path to advancement for individual women, but there were limits to their overall effect on the gender imbalance in computing. The numbers of women members, office holders, and award winners remained relatively small. ACM, for example, showed little increase in the proportion of women between membership surveys conducted in 1976 (88 percent male, 10 percent female, 2 percent no answer) and 2007 (87 percent male, 13 percent female).57 These low numbers hint at the hidden obstacles that women often faced. Many did not have the luxury of devoting time to unpaid professional activities. Women were disproportionately concentrated at teaching-oriented universities and two-year colleges with high course loads, many were trying to balance work and family, and some were using whatever free time they had to earn an advanced degree. Travel could also be a hardship, especially for women who worked outside North America. Chris Warner, who began

Gender in Academic Computing   165

teaching computer science at the Open University after earning her master’s in 1975, described how a senior male colleague discouraged her from pursuing a Ph.D.: “He just said, ‘If you want to do that, you’re going to be traveling around Europe and the States. It’s not worthwhile unless you can devote the time to that. And you’ve got a family. Is that your choice—that you want to leave your family in England whilst you do the European circuit of conferences?”58 Warner dropped the idea of pursuing the Ph.D. and chose to go into academic administration instead. One wonders if her colleague would have given the same advice to a man with similar ambitions. Certainly, there was no notion in the 1970s that a computer science conference might provide childcare so that attendees would not have to make such a choice. But although professional groups were no panacea for women’s underrepresentation, they provided some individuals with important opportunities to gain personal recognition and to build communities and journals around their research interests. They also provided a springboard for women to launch their own organizations and events. A Room of Their Own: Computer Science Forums for Women [At an ACM conference,] I ran into a friend of mine in the bathroom. We began talking about why there were so few women. Each time someone came in, she joined the conversation. It’s a little bathroom with only two stalls, and we wound up with about eight of the women from the conference crammed in there, talking about it! We said, “You know, we should meet somewhere else.” —Anita Borg, 200159

Some of the most significant interventions aimed at changing the gendered culture of computer science were pioneered by Anita Borg (figure 5.2). An irrepressible spirit who was raised by unconventional parents, Borg was determined to make her professional life fit her personal lifestyle. She majored in computer science at New York University in the late 1960s but did not initially plan to go on for the Ph.D.: “At that time, I was living with a lawyer, and our plan was: we were going to hop in our van with our two big motorcycles, and we were going to move to Oregon. He was going to be a hippie lawyer, and I was going to be a hippie programmer, and we were going to have hippie babies and grow pot in the backyard!” But her professors at NYU urged her to continue her studies in computer science, and after earning her Ph.D. in 1981, she emerged as a star of operating systems research (as described above).

166  Chapter 5

Figure 5.2 Anita Borg. Photo courtesy of the Anita Borg Institute.

Borg’s first initiative for women was the product of an experience at the ACM Symposium on Operating System Principles (SOSP) in 1987. An ad hoc discussion with several colleagues in the women’s bathroom— the only space at the conference where females were not vastly outnumbered—led them to organize a dinner meeting of most of the women at the conference. At the dinner, Borg collected email addresses and set up a mailing list so that they could keep in touch. Mailing lists may seem mundane today, but in 1987 they were still a new phenomenon. Some computer scientists did not even have externally reachable email addresses, and keeping up with a dispersed virtual community was not something that people took for granted. The now-popular listserv application had only just been introduced in 1986. Borg ran her own list using an experimental email program that she was developing called Mecca. Because the initial members were women who worked in operating systems research, Borg gave her list the name “Systers.” In Borg’s view, Systers marked the transition from a set of scattered, isolated women in computer science to an actual community with a collective sense of identity. She recalled that “Before Systers existed, there was no community of women in computing. We all existed as individuals. We had a few women

Gender in Academic Computing   167

that we knew, but there was no community.”60 Many women had no female colleagues at their home institutions and were literally unaware of the existence of other women in the field, beyond the few that they happened to meet at conferences. Being able to share advice and experiences with other women on a regular basis was a radically empowering change. In addition, the list (which is moderated) established an etiquette for interaction that many women found more appealing than the macho and egotistical behavior that some felt characterized other computing forums. As word about Systers spread and female computer scientists in other research areas asked to join, Borg broadened the membership to all technical women in computing. The current description of Systers’ mission presents an implicit critique of the masculine conventions of much online communication. According to the list’s “Frequently Asked Questions” section, a central part of its mission is to create a welcoming environment, implying that this cannot be taken for granted but must be actively defended by the members: “We are a supportive organization and we are not here to tear each other down. . . . We want to create an atmosphere where women feel free to post their opinions, concerns, problems, and joys to other women in the same situation.”61 Members are urged to be “polite and respectful” and warned that unlike some other discussion forums, angry posts (“flames”) will not be tolerated, and abusive members may be removed by the moderator. Systers has also spawned separate lists for subgroups of its membership, such as lesbian, gay, bisexual, and transgender women, who wanted their own safe spaces for discussion. A particularly revealing response to the masculine bias of much online computer science discourse is a Systers list called TechTalk, which was set up for “purely technical topics—ones that don’t have any women-specific aspects.” At first the existence of such a list seems surprising. Why have a list for women that intentionally avoids “women-specific” issues? TechTalk addresses the problem that women often experience other technical lists as hostile: “The list exists because some systers feel that existing technical lists with both men and women participants have an intimidating flavor and have asked for a way for women to ask technical questions in a less antagonistic forum. The usual systers rules about treating each other with respect are strongly honored and enforced on this list.”62 The FAQ for the main systers list also notes, “We allow people to ask for help

168  Chapter 5

on purely technical topics . . . because many women feel uncomfortable asking certain types of questions on lists dominated by men.” These comments reveal that what is usually regarded as “purely technical” discussion is actually gendered: the aggressive tone in which many online technical debates are conducted is felt as masculine and alienating by some women who would otherwise be interested in the technical content. Rather than concluding that it is impossible to be both feminine and technical or that women must accept and adopt the aggressive style as inherent in the nature of technical discourse, TechTalk challenges the masculine norm by offering a less confrontational mode as an equally valid alternative. Building on the success of Systers, Borg decided to bring members of the Systers community together face to face at their own conference. In 1994 she met with her friend Telle Whitney, a chip designer and manager at Actel Computers Ltd who had met Borg in 1986, to discuss how this could be done. For Borg, a crucial strategy for legitimizing a conference that focused on women was to highlight technical rather than social issues. As she and Whitney planned the first conference, they asked, “What kind of a conference could we have where somebody’s boss would pay for them to go—where you could use money that wasn’t out of your own pocket to go to this conference? And we thought: a technical conference.”63 Technical conferences are one of the central practices of computer science. As ACM president David Patterson observed in 2004, “Research conferences are often the most desirable venues for presenting our research results. For academic computer scientists and engineers, preferring conferences over journals [is] common.”64 Positioning women in computing as a research community that is engaged in a sanctioned informationsharing activity would cast them as contributors rather than victims. As Borg noted, having a technical focus would also make it easier to obtain funding. Borg was aware that the external trappings of status would be seen, to some extent, as a measure of the intellectual seriousness of the venture: “I’ve been to lots of get-togethers about women, and it’s always on the cheap. This was not going to be on the cheap. . . . It was going to be as high-class as SOSP or any other really good computer science conference.”65 Initial sponsorship came from the Computer Research Association, a nonprofit advocacy group for academic computer science that had started a women’s committee in 1991, and also from the ACM, the IEEE Computer Society, the National Science Foundation, and several

Gender in Academic Computing   169

corporations. Borg and Whitney named the meeting the Grace Hopper Celebration of Women in Computing (GHC) to honor that famous pioneer and role model, who had died two years earlier in 1992. The first conference was planned to accommodate 400 people, but 450 attended; Borg recalled that another 100 had to be turned away. The keynote speaker was Anita Jones, director of Defense Research and Engineering for the U.S. Department of Defense, and attendees flocked to see other notable speakers, including Fran Allen, Ruzena Bajcsy, Susan Graham, Barbara Liskov, Irene Greif of Lotus, and Karen Spärck Jones of Cambridge.66 The success of the first conference led to a second in 1997, and after being held every two or three years for a decade, the event became annual in 2006.67 In addition to women who are based in computer science departments, the conference draws attendees from a variety of engineering, mathematical, and information-oriented disciplines. GHC has inspired smaller regional conferences, including a London Hopper Colloquium in 2004, the Ohio Celebration of Women in Computing in 2005, and subsequent regional events in Indiana, Michigan, Colorado, New Mexico, Kentucky, and Ontario. The first overseas conference, GHC India, was launched in 2010.68 Each of these incarnations has provided women a chance to meet, network, and recognize each other’s achievements (figure 5.3). One of Borg’s deepest insights was that a technical conference for women had the potential to expose the prevailing culture of computer science as being masculine rather than gender neutral. Gender has shaped computer science conferences in multiple ways: the sheer numerical domination of males can make women feel visibly “out of place”; social roles that assign women primary responsibility for childcare make conference attendance more difficult; and certain styles of professional interaction are associated with stereotypes of masculinity (aggressive, egotistical) or femininity (cooperative, sharing). By highlighting rather than ignoring these gendered aspects, GHC opened the door to questioning their desirability and proposing alternatives. Whitney recalled the emotional impact of being surrounded by other women at a technical event: “I had worked in the chip industry my whole professional life, and loved it. . . . But to walk into a room with all these women—I mean, nine times out of ten I’m the only woman in the room, and I have been most of my professional life, and it was just something that was both moving and very different.”69 Such an experience was (and

170  Chapter 5

Figure 5.3 Poster for the Grace Hopper Celebration of Women in Computing, Atlanta, Georgia, September 28 to October 2, 2010. Hopper is depicted on the right. Image courtesy of the Anita Borg Institute.

Gender in Academic Computing   171

is) unusual. ACM’s membership in 2007 was only 13 percent female. The numbers at mainstream computer science conferences, even in areas with a relatively high proportion of women, have been similarly low. For example, the 2008 ACM Object-Oriented Programming, Systems, Languages, and Applications conference (one of the few that offered financial support for childcare) had 10 percent female attendance, and there were only 16 percent women among the first authors on the 2007 program of SOSP, the conference at which Anita Borg had begun her community-building efforts.70 Changing these numbers can have qualitative impacts. At least one study has shown that as the proportion of women in a computer science environment increases, women become more confident, and differences in men’s and women’s attitudes toward computer science become less pronounced.71 By creating an event where women are in the majority and are publicly engaged in scientific practice, GHC also works against popular stereotypes to paint an alternative image of computer science as female-friendly and of women as comfortable with technology.72 In 2008, GHC became possibly the first computer science conference to provide free, on-site childcare. This made it more feasible for women with children to attend and also symbolically validated family life as something that can be openly combined with professional work rather than kept invisible, as women used to feel pressured to do (as was shown in chapter 4). One grateful attendee commented, “It means that I can be my career self and my personal self at the same time and in the same place/space, and that I don’t have to hide either identity!”73 GHC further challenges gendered norms by reshaping the predominant style of professional interaction. Masculine stereotypes of leadership can leave women caught between either adopting that persona or being perceived as weak. Fran Berman, the director of the San Diego Supercomputer Center from 2001 to 2009, noted this dilemma: “I’m the first woman Supercomputer Center director ever, and I have a different leadership style than my colleagues. . . . If people know you’re a reasonably nice person, a team player, they don’t think you’re going to make hard decisions; they don’t think you’re necessarily going to have vision; they don’t think you’re necessarily credible. . . . Because you’re not what people expect a director to look like.”74 She believed, however, that after going through an initial “credibility-establishing phase,” female leaders would be treated equally. Berman emphasized that her job required her to

172  Chapter 5

be just as tough and competitive as her male colleagues and that she was not advocating an easier “girl job” for women in computer science. But she did suggest, through her use of metaphor, that women needed models of toughness that they could relate to: “One thing that I think is really true is that what drives me is not necessarily the same as what drives my [male] colleagues. . . . Sometimes I think my colleagues go out there, and their mental image is, ‘Kill the infidels!’ . . . And I always go out there and I think, ‘I must protect my cubs!’”75 Like Berman, Borg hoped to provide alternate models for intellectual authority that would not require women to adopt a male persona. Borg recalled wondering as she planned the first conference, “What would a technical conference that was almost all female be like? Would it be the same? I don’t think so! I think it would be wildly different.” In practice, she found that interactions at GHC were less self-aggrandizing than at other conferences she had attended: “Women are there to share what they’re learning, not to beat their chests and puff up and brag about what they’re doing.” She quoted Ruzena Bajcsy, a featured speaker at the first conference, as marveling, “It’s so amazing! There’s no ego!”76 A 2009 attendee made a similar point, noting how “exhausting” she had found other technical events: “At the typically male-dominated technical conferences I had attended in the past, it required thoughtful, concerted effort to interact with male peers. . . . I felt like I was always ‘on,’ inadvertently focusing on the status dimension,” but at GHC, “I could just be myself.”77 Participating in GHC allows attendees, particularly students, to apply a critical perspective to the dominant mode of interaction in computer science. Borg hoped that by attending GHC and experiencing computer science in a different mode, young women could envision an alternative professional world: “Students learn that there’s an entirely different way of interacting. So even though they go to these other conferences, and they know that it’s rough, they see that it’s not the only way things can go.”78 Although women still have to spend most of their time in the dominant culture, they realize that they do not have to accept it unquestioningly as the only or best way: GHC proves that a masculine style of interaction is not necessary for good science. The consciousness-raising mission of GHC is also reflected in Borg’s and Whitney’s intention that there should be some men among the conference attendees. In Borg’s view, when men are exposed to a female-friendly version of professional behavior, “then

Gender in Academic Computing   173

they get it, then they understand that it’s different.”79 The implication is that men who “get it” will agree that this new mode of interaction is an improvement—or at least equally valid as the masculine norm. In terms of content, GHC differs from mainstream conferences in a variety of ways. Only about half of the conference program is devoted to traditional technical presentations. The other sessions offer celebrations of women’s achievements and advice for women at various stages of their careers. GHC also reinterprets the meaning of computer science by emphasizing, more than most conferences, the connections between the technical and the social. A number of studies have indicated that women find computer science more appealing when the theoretical aspects are linked to real-world applications with social utility.80 These connections are made explicit in GHC conference themes such as “We Build a Better World” (2008), “Creating Technology for Social Good” (2009), and “Collaborating across Boundaries” (2010), which both reflect and legitimize women’s greater interest in socially relevant computing. A 2008 survey of GHC attendees found that broadening the meaning of computer science beyond the abstractly technical resonated with them, with 65 percent of respondents rating “sessions featuring the social impact of technology” as “very valuable.”81 The conference format also seems to be effective in encouraging women to stay in the field: the 2008 survey found that 70 percent of respondents reported increased commitment to a technology career, and 88 percent of those who had attended previous GHCs felt that they had already benefited in terms of professional advancement.82 GHC differs from most computer science events in being a generalinterest conference that cuts across all research areas and aims to serve a technically diverse group of women. Virtually all of the top-ranked computer science conferences are in specialized areas, and no conference ranking lists have a category for general-interest conferences, making GHC invisible when computer science is seen as simply a collection of specialties.83 Yet this perspective has come under critique. ACM president David A. Patterson wrote an open letter to the ACM community in 2004 decrying the lack of “big idea papers” at conferences, which he attributed in part to their highly specialized nature and low acceptance rates (between 15 and 25 percent). Under these conditions, he argued, rigorous but narrow and intellectually conservative papers would win out in the selection process over bolder but rougher offerings.84 Although the broad scope of

174  Chapter 5

GHC’s program is only indirectly related to gender, it could be seen as a fortuitous corrective to the narrowness of mainstream computer culture. A more deliberate intervention is GHC’s inclusive policy toward poster sessions, another staple of technical conferences. GHC’s acceptance rate of 25 percent for panels, papers, and presentations is in line with other conferences, but the acceptance rate for posters is close to 100 percent. As Deanna Kosaraju, vice president of programs, explained, “We want to provide women the opportunity to find their voices. . . . So for posters, we want women to showcase what they are most passionate about, and we have 200 posters in the poster session. I think we provide an opportunity where other conferences fall flat.”85 Broad visions and “big ideas” have some chance of being heard. The Grace Hopper Celebration illustrates some of the possibilities and limitations of building research communities that embrace a specific identity rather than claiming a stance of neutrality. GHC enacts an alternative culture of computer science that provides both a relief from and an implicit critique of its male-oriented culture. It offers women moral support, visibility, and practical advice on getting ahead in the academic world, and it may foster collaborative research efforts among participants. Yet GHC does not seem yet to have been a catalyst for change in the larger world of computer science conferences, perhaps because it does not fit the disciplinary norms of highly specialized content and formally published proceedings. GHC remains an oasis rather than a model. Anita Borg followed Systers and GHC with a third initiative in 1997— a research center that focuses on gender and technology. Drawing on her network of professional contacts, she raised funds from various IT corporations to set up what she called the Institute for Women and Technology (IWT). In addition to running Systers and GHC, IWT experimented with involving ordinary women in the design of computer-based applications. This was meant to challenge the notion that technical design is gender neutral. In Borg’s view, technologies cannot fully meet women’s needs or preferences unless women are involved as decision makers. Eventually, IWT’s focus settled more on mentoring and recognizing technical women, both in academia and industry, and expanded internationally to include female computer professionals around the world, including in developing nations. IWT was renamed the Anita Borg Institute after Borg’s untimely death in 2003.

Gender in Academic Computing   175

Conclusions There is little common or stereotypical about the women who make their careers in computing. We are from all walks of life. We are all types of people. Whatever else, we are drawn to the challenges presented by computing, by the thrill of solving problems, by the speed, power, complexity and potential of the machines we create and use. —Anita Borg, 199486

With determination and ingenuity, a wide range of women have been successful at making computer science their intellectual and professional home. Women’s strategies ranged from individually improvised careers to collective institution building. In the era informed by feminism, their activism went beyond simply trying to make the best of the existing opportunities to challenge the very culture of computer science. Events such as GHC radically reimagined computing, denying any sharp separation of the technical and the social and exposing “neutral” modes of interaction as masculine norms that might be worth changing. One consistent thread in these narratives, echoing the earlier experiences of software entrepreneurs, has been the importance of social support from spouses, managers, colleagues, and networks of female peers. This reaffirms the value of efforts such as conferences and mentoring programs that broaden and institutionalize women’s support networks. Another familiar theme is the need to support computer scientists’ ability to be parents, through provisions such as on-site childcare and flexible or reduced hours. This implies a revamped notion of achievement that adjusts expectations to the individual’s life situation and does not reduce the respect and rewards for those with families. Such provisions would make professional life easier for women, who still carry the major responsibility for childcare, and would also make it easier for male computer scientists to share more of the joys and burdens of childcare. We have glimpsed how some remarkable women managed to thrive in computer science despite the odds. Perhaps their stories can inspire future initiatives toward gender equity.

Appendix: Oral History Interviews Conducted For This Project

Transcripts of all interviews conducted by the author for this project are available online in the IEEE Oral History Collection, part of the IEEE Global History Network, http://www.ieeeghn.org. Fran Allen (U.S.), August 2, 2001 Jean Bacon (UK), April 10, 2001 Ruzena Bajcsy (U.S.), July 9, 2002 Jean Jennings Bartik (U.S.), August 3, 2001 Fran Berman (U.S.), July 18, 2002 Mary Lee Berners-Lee (UK), September 12, 2001 Susan Bond (UK), September 26, 2001 Anita Borg (U.S.), January 5, 2001 Betty Campbell (U.S.), February 13, 2001 Rosemary Candlin (UK), September 19, 2001 Judy Clapp (U.S.), February 11, 2001 Mary Coombs (UK), September 25, 2001 Betty Cooper (UK), September 14, 2001 Marge Devaney (U.S.), April 4, 2002 Jean Dollimore (UK), April 4, 2001 Thelma Estrin (U.S.), July 19, 2002 Elizabeth “Jake” Feinler (U.S.), July 9, 2002 Adele Goldberg (U.S.), July 3, 2002 Fan Chung Graham (U.S.), July 18, 2002 Susan Graham (U.S.), July 10, 2002

178  Appendix

Lois Haibt (U.S.), August 2, 2001 Ann Hardy (U.S.), July 15, 2002 Paula Hawthorn (U.S.), July 5, 2002 Marlene Hazle (U.S.), February 11, 2001 Bobby Hersom (UK), September 20, 2001 Kathy Humphry (UK), September 17, 2001 Eleanor Ireland (UK), April 23, 2001 Hilary Kahn (UK), April 18, 2001 Laurie Keller (UK), September 26, 2001 Mary Kircher (U.S.), April 3, 2002 Heather Liddell (UK), April 4, 2001 Barbara Liskov (U.S.), February 8, 2001 Joyce Currie Little (U.S.), September 9, 2002 Gillian Lovegrove (UK), September 20, 2001 Margaret Marrs (UK), April 9, 2001 Mary Menzel (U.S.), April 4, 2002 Judith Mills (UK), April 19, 2001 Pam Morton (UK), April 6, 2001 Jean Sammet (U.S.), August 29, 2001 Carol Shanesy (U.S.), August 1, 2001 Karen Shipp (UK), September 11, 2001 Stephanie “Steve” Shirley (UK), April 20, 2001 Elsie Shutt (U.S.), February 9, 2001 Barbara Simons (U.S.), July 11, 2002 Lucy Slater (UK), April 9, 2001 Karen Spärck-Jones (UK), April 4, 2001 Pat Stewart (UK), April 11, 2001 Chris Warner (UK), April 24, 2001 Telle Whitney (U.S.), July 16, 2002 Sylvia Wilbur (UK), April 4, 2001 Emily Willbanks (U.S.), April 5, 2002 Diane Wray (UK), April 5, 2001

Notes

Introduction 1.  Elsie Shutt, interview by Janet Abbate, February 9, 2001. 2.  Fran Allen, interview by Janet Abbate, August 2, 2001. 3.  Paula Hawthorn, interview by Janet Abbate, July 5, 2002. 4. Tracy Camp, “The Incredible Shrinking Pipeline,” Communications of the ACM 40, no. 10 (1997): 103–110. 5.  See, for example, Carol J. Burger, Elizabeth G. Creamer, and Peggy S. Meszaros, eds., Reconfiguring the Firewall: Recruiting Women to Information Technology across Cultures and Continents (Wellesley, MA: A. K. Peters, 2007); Camp, “The Incredible Shrinking Pipeline”; J. McGrath Cohoon and William Aspray, eds., Women and Information Technology: Research on Underrepresentation (Cambridge: MIT Press, 2006); Jane Margolis and Allan Fisher, Unlocking the Clubhouse: Women in Computing (Cambridge: MIT Press, 2002); Ellen Spertus, Why Are There So Few Female Computer Scientists? (Cambridge: MIT Artificial Intelligence Laboratory, 1991); Chuck Huff, “Gender, Software Design, and Occupational Equity” (Inroads: SIGCSE Bulletin 34, no. 2 (2002): 112-15). For a general policy study on women in science, see National Academies, Beyond Bias and Barriers: Fulfilling the Potential of Women in Academic Science and Engineering (Washington, DC: National Academies Press, 2006). 6. As Sandra Harding observes, “Gender symbolism is the result of assigning dualistic gender metaphors to various perceived dichotomies that rarely have anything to do with sex differences.” Sandra Harding, The Science Question in Feminism (Ithaca, NY: Cornell University Press, 1986), 17. The classic text arguing that scientific objectivity is a masculine construct is Carolyn Merchant, The Death of Nature: Women, Ecology and the Scientific Revolution (New York: Harper & Row, 1980). 7.  See Judith Butler, Gender Trouble (New York: Routledge, 1990), for an extended analysis of gender as a performance. 8.  Ekaterina Alexeevna Shkabara was one of three main designers of the MESM computer, completed in 1951. Boris Nikolaevich Malinovsky, Pioneers of Soviet Computing, trans. Emmanuel Aronie and ed. Anne Fitzpatrick and Kate Maldonado, http://www.sigcis.org/files/sigcismc2010_001.pdf, 2010, 13.

180  Notes

9. See, e.g., Autumn Stanley, Mothers of Invention (Metuchen, NJ: Scarecrow, 1984); Martha Moore Trescott, ed. Dynamos and Virgins Revisited: Women and Technological Change in History (Metuchen, NJ: Scarecrow Press,1979); Margaret Rossiter, Women Scientists in America: Strategies and Struggles to 1940 (Baltimore: Johns Hopkins, 1982); Margaret Rossiter, Women Scientists in America: Before Affirmative Action, 1940–1972 (Baltimore: Johns Hopkins, 1995); Londa Schiebinger, The Mind Has No Sex? Women in the Origins of Modern Science (Cambridge: Harvard University Press, 1989). 10.  Charlotte Bunch, Passionate Politics: Feminist Theory in Action (New York: St. Martin’s Press, 1987). 11.  For an early study of masculinity in computing, see Margaret Tierney, “Negotiating a Software Career: Informal Work Practices and ‘the Lads’ in a Software Installation,” in The Gender-Technology Relation: Contemporary Theory and Research, ed. Keith Grint and Rosalind Gill (London: Taylor & Francis, 1995), 197–209. 12.  The main academic journal in this area is the IEEE Annals of the History of Computing. Books on the history of computing are too numerous to mention. Good scholarly overviews include Martin Campbell-Kelly and William Aspray, Computer: A History of the Information Machine (New York: Basic Books, 1996) and Paul E. Ceruzzi, A History of Modern Computer (Cambridge: MIT Press, 1998). A classic journalistic work is Tracy Kidder, The Soul of a New Machine (New York: Avon, 1981). 13.  For recent exceptions, see David Alan Grier, When Computers Were Human (Princeton: Princeton University Press, 2005); Jennifer S. Light, “When Computers Were Women,” Technology and Culture 40, no. 3 (1999): 455–483; Thomas Misa, ed., Gender Codes: Why Women Are Leaving Computing (Hoboken, NJ: Wiley, 2010); Betty Campbell, ed., Special issue on Women in Computing, Annals of the History of Computing, 18, no. 3 (1996); Janet Abbate, ed., Special issue on Women and Gender in the History of Computing, Annals of the History of Computing 25, no. 4 (2003). 14.  For women in science, see Schiebinger, The Mind Has No Sex? Women in the Origins of Modern Science; Rossiter, Women Scientists in America: Strategies and Struggles to 1940; Rossiter, Women Scientists in America: Before Affirmative Action, 1940–1972. 15.  For example, Kurt W. Beyer, Grace Hopper and the Invention of the Information Age (Cambridge: MIT Press, 2009), comments that ENIAC and UNIVAC programmer Betty Holberton, who was considered an outstanding talent by those who knew her work, never received recognition because she did not push herself forward. 16.  Betty A. Toole, Ada, the Enchantress of Numbers: Prophet of the Computing Age (Witney, UK: Strawberry Press, 1998); Kathleen Broome Williams, Grace Hopper: Admiral of the Cyber Sea (Annapolis: Naval Institute Press, 2004); Beyer, Grace Hopper and the Invention of the Information Age; W. Barkley Fritz, “The Women of ENIAC,” Annals of the History of Computing 18, no. 3 (1996): 13–28.

Notes  181

17.  The neglect of software has been partly remedied by the founding in 1987 of what is now the Software Industry Special Interest Group of the Computer History Museum by Luanne Johnson and Burt Grad. See also Martin Campbell-Kelly, From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry (Cambridge: MIT Press, 2003). Michael S. Mahoney was an influential theorist on the nature of computer science. Relevant works include Michael S. Mahoney, “Computer Science: The Search for a Mathematical Theory,” in Science in the Twentieth Century, ed. John Krige and Dominique Pestre (Amsterdam: Harwood Academic, 1997), 617–634; and Michael S. Mahoney, “Software as Science, Science as Software,” in History of Computing: Software Issues, ed. Ulf Hashagen, Reinhard Keil-Slawik, and Arthur Norberg (Berlin: Springer Verlag, 2002), 25–48. William F. Aspray has published on the mathematical foundations of computer science. William Aspray, John Von Neumann and the Origins of Modern Computing (Cambridge: MIT Press, 1990); William Aspray, “Command and Control, Documentation, and Library Science: The Origins of Information Science at the University of Pittsburgh,” Annals of the History of Computing 21, no. 4 (1999): 4–20; William Aspray, “Was Early Entry a Competitive Advantage? U.S. Universities That Entered Computing in the 1940s,” Annals of the History of Computing 22, no. 3 (2000): 42–87. Philip Kraft was one of the first to attempt a labor history of programming. Philip Kraft, Programmers and Managers (New York: Springer, 1977). 18. Kraft, Programmers and Managers; Philip Kraft, “The Routinization of Computer Programming,” Sociology of Work and Occupations 6, no. 2 (1979): 139–155; Joan Greenbaum, In the Name of Efficiency: Management Theory and Shopfloor Practice in Data-Processing Work (Philadelphia: Temple University Press, 1979). 19. See, e.g., Nathan L. Ensmenger, “Letting the ‘Computer Boys’ Take Over: Technology and the Politics of Organizational Transformation,” International Review of Social History 48, suppl. (2003), 153–180. 20.  Seán Ó Riain, “Net-Working for a Living: Irish Software Developers in the Global Workplace,” in The Critical Study of Work: Labor, Technology, and Global Production, ed. Rick Baldoz, Charles Koeber, and Philip Kraft (2001), 258–282; Stephen R. Barley and Gideon Kunda, Gurus, Hired Guns, and Warm Bodies: Itinerant Experts in a Knowledge Economy (Princeton, NJ: Princeton University Press, 2004). 21.  Thomas Haigh, “Inventing Information Systems: The Systems Men and the Computer, 1950–1968,” Business History Review 75 (2001): 15–61; Ensmenger, “Letting the ‘Computer Boys’ Take Over.” 22. Grier, When Computers Were Human; Marie Hicks, “Meritocracy and Feminization in Conflict: Computerization in the British Government,” in Gender Codes: Why Women Are Leaving Computing, ed. Thomas Misa (Hoboken, NJ: Wiley, 2010), 95–114; Nathan Ensmenger, “Making Programming Masculine,” in Gender Codes: Why Women Are Leaving Computing, ed. Thomas Misa (Hoboken, NJ: Wiley, 2010), 115–141. 23.  Judy Wajcman, “Patriarchy, Technology, and Conceptions of Skill,” Work and Occupations 18, no. 1 (1991), 37–38.

182  Notes

Chapter 1 1. Quoted in text accompanying exhibit on Wrens, Bletchley Park museum, viewed September 2001. 2.  Archives of the University of Pennsylvania, ENIAC Papers, box 12, ff 11, Deposition of Jean J. Bartik, May 12, 1971, 32. 3. I am not concerned here with priority claims, but there is considerable debate in the historical literature about which machine deserves to be called the first digital computer. The verdict depends on which aspects of the machine are considered essential to the definition (for example, fully electronic rather than electromechanical, stored program or reading programs from external media, general purpose or specialized). Good overviews of the history of computing machines include Paul E. Ceruzzi, A History of Modern Computing (Cambridge: MIT Press, 1998), and Martin Campbell-Kelly and William Aspray, Computer: A History of the Information Machine, Sloan Technology Series (New York: Basic Books, 1996). 4.  David Alan Grier, “The Math Tables Project of the Work Projects Administration: The Reluctant Start of the Computing Era,” Annals of the History of Computing 20, no. 3 (1998): 33–50; David Alan Grier, When Computers Were Human (Princeton: Princeton University Press, 2005); Mary Croarken, “Mary Edwards: Computing for a Living in Eighteenth-Century England,” Annals of the History of Computing 25, no. 4 (2003): 9–15. 5. Campbell-Kelly and Aspray, Computer: A History of the Information Machine, 47–51. 6. Ibid. 7. For Konrad Zuse, see J. A. N. Lee’s history of computing site, http://ei.cs .vt.edu/~history/Zuse.html, which includes the transcript of a talk by Zuse on computer design, and the site created by computer scientist Horst Zuse (Konrad’s son) at http://user.cs.tu-berlin.de/~zuse/konrad-zuse.html. 8. See Raul Rojas and Ulf Hashagen, eds., The First Computers: History and Architectures (Cambridge: MIT Press, 2002), for more information on the firstgeneration digital computers. 9. The origins of the stored-program concept are the subject of continuing debate. See William Aspray, “The Stored Program Concept,” IEEE Spectrum 27 (1990): 51, for an overview. 10.  Jack Good, Donald Michie, and Geoffrey Timms, “General Report on Tunny,” Bletchley Park, 1945. The Tunny report, which describes Colossus and other codebreaking machines at Bletchley Park, was classified until 2000. It is now available online at the Alan Turing archive, http://www.alanturing.net/turing_ archive/archive/index/tunnyreportindex.html. 11.  Parallel codebreaking activities in the United States included a navy-run operation at Arlington Hall near Washington, D.C., that focused on cracking Japanese encryption. As at Bletchley Park, women played a key role operating codebreaking “bombes.” Laurie Robertson, “Arlington Hall Station: The U.S. Army’s World

Notes  183

War II Cryptoanalytic Center,” Annals of the History of Computing 26, no. 2 (2004): 86–89. 12.  Tony Sale provides a lucid, illustrated explanation of the Lorenz machine at http://www.codesandciphers.org.uk/virtualbp/fish/fish.htm. 13.  Given the limitations of surviving records, I have been unable to determine the exact number of operators. I arrived at my estimate as follows: There were, at the peak, twenty women per shift (two at each of ten Colossus computers). There were three shifts per day, for a total of sixty women. Because there was some turnover of personnel, the total number of women who worked on Colossus over the course of the war is probably somewhat higher. By April 1945, the total number of Wrens working in Max Newman’s section, which included the Colossus and Tunny operations and a tape registry, was 273. Good, Michie, and Timms, “General Report on Tunny,” 276. 14.  Thomas H. Flowers, “D-Day at Bletchley Park,” in Colossus: The Secrets of Bletchley Park’s Code-Breaking Computers, ed. B. Jack Copeland (Oxford: Oxford University Press, 2006), 81. An assessment of the overall contribution of the British codebreaking activities can be found in F. H. Hinsley, “The Influence of Ultra in the Second World War,” in Codebreakers: The Inside Story of Bletchley Park, ed. F. H. Hinsley and Alan Stripp (Oxford: Oxford University Press, 1993). 15.  “Ode to the Eniac,” Chicago Daily Tribune, February 18, 1946, 12. 16.  Campbell-Kelly and Aspray, Computer: A History of the Information Machine, 81–83. 17.  Surnames in parentheses are later married names. For consistency, I refer to the women throughout by the maiden names they had during the project. 18.  Herman H. Goldstine, The Computer from Pascal to Von Neumann (Princeton: Princeton University Press, 1972), 234–235. 19.  Quoted in W. Barkley Fritz, “The Women of ENIAC,” Annals of the History of Computing 18, no. 3 (1996): 16. 20.  David M. Kennedy, Freedom from Fear: The American People in Depression and War, 1929–1945 (New York: Oxford University Press, 1999), 778. 21.  I am indebted to Amy Slaton for insights on this point. For the racial division of technical labor, see Amy Slaton, Race, Rigor, and Selectivity in U.S. Engineering: The History of an Occupational Color Line (Cambridge: Harvard University Press, 2010). 22.  Jennifer S. Light, “When Computers Were Women,” Technology and Culture 40, no. 3 (1999): 461. 23.  Quoted in Doris Kearns Goodwin, No Ordinary Time: Franklin and Eleanor Roosevelt: The Home Front in World War II (New York: Simon & Schuster, 1994), 414. 24.  Fritz, “The Women of ENIAC,” 14. 25.  Quoted in W. Barkley Fritz, “ENIAC: A Problem Solver,” Annals of the History of Computing 16, no. 1 (1994): 28.

184  Notes

26.  During my 2001 interview with Jean Jennings Bartik, she showed me the promotion letter that officially changed her job title from computer (subprofessional grade 6) to mathematician (professional grade 2) in January 1946. Ensmenger states that the ENIAC women were called coders, but this seems to be based solely on a publication by Goldstine and von Neumann and does not match the usage that I found in other published sources or interviews. Nathan Ensmenger, The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise (Cambridge: MIT Press, 2010), 35. 27. There were a few female mathematicians at Bletchley Park, but apparently none was assigned to the Colossus area, which was a relatively small part of the mathematicians’ work. 28.  B. Jack Copeland et al., “Mr. Newman’s Section,” in Colossus: The Secrets of Bletchley Park’s Code-Breaking Computers, ed. B. Jack Copeland (Oxford: Oxford University Press, 2006), 159. About 4 percent of British men received college degrees in 1950, the first year after 1939 for which statistics are available. Central Statistical Office (UK), Annual Abstract of Statistics, vol. 97 (London: Her Majesty’s Stationery Office, 1960). 29.  My description of the experiences of Bletchley Park Wrens draws on Gwendoline Page, ed., We Kept the Secret: Now It Can Be Told—Some Memories of Pembroke V Wrens (Wymondham, UK: Reeve, 2002); Marion Hill, Bletchley Park People: Churchill’s “Geese That Never Cackled” (Stroud, UK: Sutton, 2004); and B. Jack Copeland, “Colossus and the Rise of the Modern Computer,” in Colossus: The Secrets of Bletchley Park’s Code-Breaking Computers, ed. B. Jack Copeland (Oxford: Oxford University Press, 2006), 101–115. 30. Eleanor Ireland, interview by Janet Abbate, April 23, 2001. The computer that Ireland saw was presumably the Heath Robinson, a prototype of the Colossus that had two tape drives instead of one. In the Colossus, the second tape drive was replaced by a set of vacuum tubes. The Heath Robinson was installed at Bletchley Park in June 1943, and the Colossus in December 1943. 31.  James K. Lively, “Technical History of 6813th Signals Security Detachment,” 1945, 15. 32.  Copeland, “Colossus and the Rise of the Modern Computer,” 166. 33. Eleanor Ireland, interview by Janet Abbate, April 23, 2001. Thanks to an anonymous reviewer for suggesting the parallel with housework. 34.  Quoted in Fritz, “The Women of ENIAC,” 22. The other programmer without a math degree was Betty Snyder. 35.  Jean Jennings Bartik, interview by Janet Abbate, August 3, 2001. 36.  Quoted in Fritz, “The Women of ENIAC,” 20. 37.  Good, Michie, and Timms, “General Report on Tunny,” 278. 38.  Eleanor Ireland, interview by Janet Abbate, April 23, 2001; Copeland et al., “Mr. Newman’s Section,” 162; Good, Michie, and Timms, “General Report on Tunny,” 278. 39.  Archives of the University of Pennsylvania, UPD 8.4, Moore School of Electrical Engineering, Office of the Director Records, 1931–1948, box 46: ENIAC

Notes  185

Material (date approx. 1940–1950), folder “DAF, Early Computer Aberdeen Course,” “Course in Mathematics for Ballistics Computations.” 40.  Quoted in Fritz, “The Women of ENIAC,” 23. 41.  Goldstine, interview with Jennifer Light, 1994, quoted in Light, “When Computers Were Women,” 469. 42.  Fritz, “The Women of ENIAC,” 19. 43.  Ensmenger calls the ENIAC programmers “glorified clerical workers.” Ensmenger, The Computer Boys Take Over, 35; see also Light, “When Computers Were Women.” 44.  John R. Mauchly, “Interview by Henry Tropp,” January 10, 1973, Computer Oral History Collection, Smithsonian Institution National Museum of American History, #196, box 13, f13, n.p. (7th page from end of ms.). 45.  Good, Michie, and Timms, “General Report on Tunny,” 334. 46.  Copeland et al., “Mr. Newman’s Section,” 163–164. Ireland pointed out that when a Colossus was rebuilt in 1996 for the new Bletchley Park museum, the male engineers discovered just how tricky it was to thread the tapes: “It took them three hours to get the tape right, and we all thought that was very amusing!” Eleanor Ireland, interview by Janet Abbate, April 23, 2001. 47.  Ibid., 163. 48.  Flowers, “D-Day at Bletchley Park,” 98. 49.  Copeland et al., “Mr. Newman’s Section,” 164. 50.  Ibid., 163. 51.  Copeland, “Colossus and the Rise of the Modern Computer,” 159, 164–165. 52.  Good, Michie, and Timms, “General Report on Tunny,” 278. 53. Ibid., 279. “Chi-breaking” meant discovering the settings of the first five wheels on the Lorenz machine. 54.  Lively, “Technical History of 6813th Signals Security Detachment,” 20. 55. Adele K. Goldstine, “A Report on the ENIAC (Electronic Numerical Integrator and Computer),” University of Philadelphia, Moore School of Electrical Engineering, Philadelphia, 1946). 56. Later, both Herman and Adele Goldstine claimed credit for preparing the ENIAC demonstration program. Light, “When Computers Were Women,” 472, 478. But the programmers themselves denied that the Goldstines had either taught them programming or created the program in question. See Archives of the University of Pennsylvania, ENIAC Papers, box 15, ff 5, “Deposition of Kathleen Rita Mauchly,” ca. 1971, 322–324; and Jean Jennings Bartik’s description of preparing the program in Fritz, “The Women of ENIAC.” 57.  Jean Jennings Bartik, interview by Janet Abbate, August 3, 2011. 58.  “Deposition of Kathleen Rita Mauchly,” 322. 59.  Archives of the University of Pennsylvania, ENIAC Papers, box 16, ff 3, “Deposition of Ruth L. Teitelbaum,” ca. 1971, 54–55.

186  Notes

60.  Quoted in Fritz, “The Women of ENIAC,” 20. 61.  Archives of the University of Pennsylvania, ENIAC Papers, box 14, ff 7, “Deposition of Frances D. Holberton,” 1971, 70–71; also “Deposition of Kathleen Rita Mauchly,” 144. 62.  Quoted in Fritz, “The Women of ENIAC,” 20. 63.  Fritz, “ENIAC: A Problem Solver,” 25; Fritz, “The Women of ENIAC,” 14. 64. Archives of the University of Pennsylvania, ENIAC Papers, box 12, ff 11, “Deposition of Jean J. Bartik,” ca. 1971, 34. 65.  Quoted in Fritz, “The Women of ENIAC,” 21. BRL is the Ballistics Research Laboratory at Aberdeen. 66.  Quoted in Fritz, “The Women of ENIAC,” 21. 67.  Ruth Milkman, Gender at Work: The Dynamics of Job Segregation by Sex during World War II (Chicago: University of Illinois Press, 1987). Alice KesslerHarris (1982) notes that American women’s postwar employment level was not significantly higher than it would have been without the war (277–278). Penny Summerfield, Women Workers in the Second World War: Production and Patriarchy in Conflict (London: Routledge, 1989), argues that in the United Kingdom, “the implementation of official policy [women’s mobilization] during the war did little to alter but rather reinforced the unequal position of women in society” (185). 68.  Eleanor Ireland, interview by Janet Abbate, April 23, 2001. 69. Grier, When Computers Were Human, 288; Light, “When Computers Were Women,” 479. 70.  “Course in Mathematics for Ballistics Computations.” 71.  Eleanor Ireland suggested that some of the Wrens who worked on Colossus went on to work with computers for the British navy in Ceylon, but I have been unable to verify this. 72.  Two Colossus machines were kept for the use of Government Communications Headquarters (the newly renamed codebreaking agency). They were actively used for fifteen more years until 1960, and their exact use is still classified. Copeland, “Colossus and the Rise of the Modern Computer,” 173. 73. For a description of the Colossus rebuild, see http://www.codesandciphers .org.uk/lorenz/rebuild.htm. 74.  Harry Fensom, “How Colossus Was Built and Operated,” in Colossus: The Secrets of Bletchley Park’s Code-Breaking Computers, ed. B. Jack Copeland (Oxford: Oxford University Press, 2006), 302. 75.  Copeland, “Colossus and the Rise of the Modern Computer,” 108, 186. Copeland argues that Colossus was the “missing link” that showed Turing and Newman how to build a stored-program computer: “In 1936 [the year that Turing wrote On Computable Numbers] the universal Turing machine existed only as an idea. Right from the start Turing was interested in the possibility of building such a machine, as to some extent was Newman. But it was not until their Bletchley Park days that the dream of building a miraculously fast all-purpose computing machine took hold of them. Before the war they knew of no practical way to

Notes  187

construct a stored-program computer: it was at Bletchley that they learned how it might be done. Large-scale electronics was the secret.” Copeland, “Colossus and the Rise of the Modern Computer,” 105. Copeland claims that Newman (and later Turing) taught engineers Tom Kilburn and F. C. Williams, who built the Manchester machines, how to design an electronic computer (112). 76.  Fritz, “ENIAC: A Problem Solver,” mentions Gloria Gordon Bolotsky, Lila Todd Butler, Ester Gersten, Winifred (Wink) Smith Jonas, Marie Malone, Helen Mark, and Homé McAllister Reitwiesner (30). 77. McNulty obituary, May 4, 2006, http://www.chestnuthilllocal.com/issues/2006.05.04/obituaries.html; Fritz, “The Women of ENIAC”; Jean Jennings Bartik, interview by Janet Abbate, August 3, 2011. 78.  C. Dianne Martin, “ENIAC: Press Conference That Shook the World,” IEEE Technology and Society Magazine 14, no. 4 (1995): 3–10. 79.  “Deposition of Jean J. Bartik,” 65; “Deposition of Frances D. Holberton,” 81; Kathy Kleiman, The Computers: The Untold Story of the Remarkable Women Who Programmed the ENIAC (Documentary Preview), 2001, http://eniacprogrammers .org. On the other hand, McNulty recalled being invited to the press lunch. “Deposition of Kathleen Rita Mauchly,” 101–102. The lack of public acclaim did not mean that the programmers went completely unrecognized. For example, Jean Jennings and Adele Goldstine created a program in fall 1946 to model the reflection of shock waves for A. H. Taub of the University of Washington, and Jennings noted that “I did receive a letter of commendation for the significant help we had given.” “Deposition of Jean J. Bartik,” 49; see also Fritz, “The Women of ENIAC,” 21. 80.  See Mitchell Marcus and Atsushi Akera, “Exploring the Architecture of an Early Machine: The Historical Relevance of the ENIAC Machine Architecture,” Annals of the History of Computing 18, no. 1 (1996): 17–24; Fritz, “The Women of ENIAC.” Kathy Kleiman wrote one of the first papers on the ENIAC women in 1986 as an undergraduate in sociology. She later shot documentary footage of many of the programmers, although a finished documentary has not been produced as of this writing. See http://eniacprogrammers.org. 81.  Light, “When Computers Were Women,” 474. 82.  Martin, “ENIAC: Press Conference That Shook the World.” 83.  Fritz, “ENIAC: A Problem Solver,” 31. 84.  Archives of the University of Pennsylvania, UPD 8.4, Moore School of Electrical Engineering, Office of the Director Records, 1931–1948, box 48, folder “PX - Publicity - ENIAC,” “Basic Items for Publicity Concerning ENIAC,” December 21, 1945.

Chapter 2 1.  Ida Russakoff Hoos, “When the Computer Takes over the Office,” Harvard Business Review 38 (1960): 104. Hoos worked for the Berkeley Institute for Industrial Relations.

188  Notes

2.  Quoted in Harold Bergstein, “It’s Elmer’s Turn,” Datamation (April 1963): 51. In 1963, Kubie’s company, CUC, employed approximately 140 people, most of them technical. Elmer C. Kubie, “Recollections of the First Software Company,” Annals of the History of Computing 16, no. 2 (1994): 68. 3.  J. C. C. Allan, “The Selection and Training of Computer Personnel in the United Kingdom,” in Proceedings of the Sixth SIGCPR Conference on Computer Personnel Research (New York: ACM, 1968), 72. 4.  Edward J. Menkhaus, “EDP: Nice Work If You Can Get It,” Business Automation (March 1969): 41. 5.  Daniel Teichroew, “Education Related to the Use of Computers in Organizations,” Communications of the ACM 14, no. 9 (1971): 579. 6.  Stuart J. Jacobs, “Cognitive Predictors of Success in Computer Programmer Training,” in Proceedings of the Eleventh SIGCPR Conference on Computer Personnel Research (New York: ACM, 1973), 98, 103. The author of the study failed to find correlations between performance on a programming exam and measures of inferential, deductive, interpretive, mathematical, or rule-recognition abilities. 7. The flexibility of skill requirements has been demonstrated by the ability of employers to make workplace accommodations to comply with the U.S. Americans with Disabilities Act (1990) or the UK Disability Discrimination Act (1995). For a historical example of how the choice of tools affects definitions of skill, Cynthia Cockburn describes how the design of printers’ tools made the ability to do heavy lifting an essential skill, thus reinforcing a male monopoly over printing jobs. Cynthia Cockburn, “The Material of Male Power,” in The Social Shaping of Technology, ed. Donald MacKenzie and Judy Wajcman (Philadelphia: Open University Press, 1985), 125–146. 8.  For technical skill as masculine, see Cynthia Cockburn, Machinery of Dominance (Boston: Northeastern University Press, 1988); Ulf Mellstrom, “Patriarchal Machines and Masculine Embodiment,” Science, Technology, and Human Values 27, no. 4 (2002): 460–478; Ruth Oldenziel, Making Technology Masculine (Amsterdam: Amsterdam University Press, 1999); S. Horrell, J. Rubery, and B. Burchell, “Unequal Jobs or Unequal Pay?,” Industrial Relations Journal 20, no. 3 (1989): 176–191. For women’s skills, see Judy Wajcman, “Patriarchy, Technology, and Conceptions of Skill,” Work and Occupations 18, no. 1 (1991): 29–45; Nina Lerman, “‘Preparing for the Duties and Practical Business of Life’: Technological Knowledge and Social Structure in Mid-Nineteenth-Century Philadelphia,” Technology and Culture 38, no. 1 (1997): 31–59; Judith A. McGaw, “Women and the History of American Technology,” Signs 7, no. 4 (1982): 798–828; Daryl M. Hafter, “The Cost of Inventiveness: Labor’s Struggle with Management’s Machine,” Technology and Culture 44, no. 1 (2003): 102–113. For useful comparisons with how attributions of technical skill are shaped by racial rather than gender bias, see William K. Storey, “Guns, Race, and Skill in Nineteenth-Century Southern Africa,” Technology and Culture 45, no. 4 (2004): 687–711; Amy Slaton, Race, Rigor, and Selectivity in U.S. Engineering: The History of an Occupational Color Line (Cambridge: Harvard University Press, 2010); Jane Margolis, Rachel Estrella, Joanna Goode, Jennifer Jellison Holme, and Kimberley Nao, Stuck in the Shallow End: Education, Race, and Computing (Cambridge: MIT Press, 2008).

Notes  189

9.  Jo Freeman, “Comparable Worth, Part I: Background,” In These Times, August 22–September 4, 1984, 16; Paula England, “The Case for Comparable Worth,” Quarterly Review of Economics and Finance 39 (1999): 743–755. As Ronnie Steinberg explains, “While not denying that skill definitions may at times reflect observable differences in levels of complexity and autonomy, comparable worth theory contends that the selection of particular types of skills and responsibilities as justifications for higher levels of compensation is socially constructed as an outgrowth of particular historical circumstances.” Ronnie J. Steinberg, “Social Construction of Skill: Gender, Power, and Comparable Worth,” Work and Occupations 17, no. 4 (1990): 454–455). The term comparable worth is used mainly in the United States and equal value in the United Kingdom. 10.  U.S. Department of Labor, Women’s Bureau, “Employment Opportunities for Women Mathematicians and Statisticians,” 1956, 24. 11.  See Martin Campbell-Kelly, “The Development and Structure of the International Software Industry, 1950–1990,” Business and Economic History 24, no. 2 (1995): 82; Jeffrey R. Yost, “Maximization and Marginalization: A Brief Examination of the History and Historiography of the U.S. Computer Services Industry,” Entreprises et Histoire 40 (2005): 92. 12.  U.S. Department of Commerce, Bureau of the Census, Statistical Abstract of the United States (Washington, DC: U.S. Government Printing Office, 1985), tables 589 and 673. The category “computer specialist” did not include key-punch operators, who were classified as clerical workers. 13. Allan, “The Selection and Training of Computer Personnel in the United Kingdom,” 66. He arrived at this number by using a ratio of approximately four programmers per machine. 14.  David Caminer, J. B. B. Aris, P. M. R. Hermon, and F. F. Land, User-Driven Innovation: The World’s First Business Computer (Maidenhead, UK: McGrawHill, 1996). 15.  B. Gilchrist and B. Weber, “Employment of Trained Computer Personnel: A Quantitative Survey,” Paper presented at the American Federation of Information Processing Societies (AFIPS) Spring Joint Computer Conference, 1972, 642. Bureau of Labor Statistics figures are not identical with the Census figures but are roughly equivalent. 16. Thomas Haigh argues that systems analysts (in the broader business sense, although including electronic data processing specialists) may have deliberately constructed a specifically masculine identity for themselves. Thomas Haigh, “Inventing Information Systems: The Systems Men and the Computer, 1950–1968,” Business History Review 75 (2001): 22. On the other hand, Elizabeth Phillips Williams describes how she and many other women were hired as systems analysts in 1943, when men were scarce. Elizabeth Phillips Williams, “A Systems Analyst’s Computer Watch: 1943–2003,” IEEE Annals of the History of Computing 24, no. 4 (2003): 27–39. 17.  Economist display ads, December 2, 1961, 977. 18.  George F. Weinwurm, ed., On the Management of Computer Programming (Philadelphia: Auerbach,1970), 5.

190  Notes

19.  “Contemporaneous writings . . . imply that the meaning of the verb ‘to program’ did not stabilize until 1951 or 1952, when the first stored program computers became operational.” David Alan Grier, “The ENIAC, the Verb ‘to Program’ and the Emergence of Digital Computers,” Annals of the History of Computing 18, no. 1 (1996): 52. In a search of U.S. newspapers, I first found the term programmer in a 1952 IBM job ad, and news articles continued to put the term in quotation marks until 1958 or so. 20. “Letter to the Editor: What’s in a Name?,” Communications of the ACM 1, no. 4 (1958): 6. M. G. Kendall of the software contractor C-E-I-R referred to programmers in 1967 as “liveware,” adding, “They are much more than mere slaves of the machine, although there is a tendency sometimes to so regard them.” M. G. Kendall, “The Long Hard Look,” London Times, special computer suppl., September 15, 1967, II. Writing about the United Kingdom in 1984, software engineering proponent Tony Hoare mentioned numerous job titles but equated them all with programmer: “We have many names—coder, systems analyst, computer scientist, informatician, chief programmer. (I will just use the word ‘programmer’ to stand for them all.).” C. A. R. Hoare, “Programming: Sorcery or Science?,” IEEE Software 1 (1984): 6. 21.  Grace Murray Hopper, “Interview by Uta C. Merzbach,” July and November 1968, Computer Oral History Collection, Smithsonian Institution National Museum of American History, 196, I-II, 7–8. 22.  Charles D. Lothridge, “Levels of Programmer Jobs,” Paper presented at the Proceedings of the Second SIGCPR Conference on Computer Personnel Research, 1964, 22. 23.  Griggs v. Duke Power Company, 401 U.S. 424, 433 (1971). The decision in Griggs v. Duke Power Company affirmed the illegality of using hiring criteria that were not directly job-related and that discriminated against groups protected under Title VII of the Civil Rights Act of 1964. 24. A 1966 survey of U.S. employers that were doing mainly business applications showed that 45 percent of their entry-level programmers came from inhouse recruitment. R. A. Dickmann and J. Lockwood, “Computer Personnel Research Group, 1966 Survey of Test Use in Computer Personnel Selection,” Paper presented at the Proceedings of the Fourth SIGCPR Conference on Computer Personnel Research, 1966, 20. 25.  P. M. A. Booth, “Training and Development Plans and Results at Mobil Data Services Ltd.,” in Proceedings of the Ninth SIGCPR Conference on Computer Personnel Research (New York: ACM, 1971), 102–103. 26.  U.S. Department of Education, National Center for Education Statistics, “Digest of Education Statistics,” 2007, table 8. 27.  Dickmann and Lockwood, “Computer Personnel Research Group, 1966 Survey of Test Use in Computer Personnel Selection,” 18. 28. Paul Bolton, House of Commons Library Standard Note, Education: Historical Statistics (London: UK Parliament, House of Commons, 2007), 15. For comparison, in 2000 about 33 percent of the UK population had participated in higher education.

Notes  191

29.  For example, a 1968 survey of computer-using organizations reported that 20 percent of senior programmers had been hired with a college degree, 40 percent with A-levels, and 40 percent based on prior programming experience. For junior programmers, 60 percent were hired with A-levels, 20 percent with O-levels, and 20 percent had experience as operators. None had a college degree. Allan, “The Selection and Training of Computer Personnel in the United Kingdom,” 73. 30.  Robert L. Patrick, “Selection Starts the Cycle,” in Proceedings of the Seventh SIGCPR Conference on Computer Personnel Research (New York: ACM, 1969), 15. 31.  Menkhaus, “EDP: Nice Work If You Can Get It,” 43. 32.  Frank Greenwood, “Some Selection Procedures,” in Proceedings of the Fifth SIGCPR Conference on Computer Personnel Research (New York: ACM, 1967), 67. 33. Bolton, House of Commons Library Standard Note, Education: Historical Statistics, 21; U.S. Department of Commerce, Bureau of the Census, Statistical Abstract of the United States, 1951, table 149; 2010, table 288. 34. Gary S. Popkin, “The Junior College as a Source of Programming Personnel,” in Proceedings of the Ninth SIGCPR Conference on Computer Personnel Research (New York: ACM, 1971), 133. 35. John J. Jensen, How to Pass Computer Programmer Aptitude Tests (New York: Cowles Education Corporation, 1967), 15. 36.  Popkin, “The Junior College as a Source of Programming Personnel,” 135– 136. 37.  The Economist, April 8, 1967, 162. 38.  Quoted in Allan, “The Selection and Training of Computer Personnel in the United Kingdom,” 71. No attempts at regulation were made other than to encourage schools to apply for government accreditation. Another UK data processing manager complained in 1971 that “Programming Schools had earned a certain degree of disrepute.” Booth, “Training and Development Plans and Results at Mobil Data Services Ltd.,” 108. 39.  Raymond M. Berger, “Selection of Systems Analysts and Programmer Trainees,” in Proceedings of the Sixth SIGCPR Conference on Computer Personnel Research (New York: ACM, 1968), 51. 40.  Sylvia Wilbur, interview by Janet Abbate, April 4, 2001. 41.  Arthur J. Bernstein, “A Programmmer Training Project,” Communications of the ACM 14, no. 7 (1971): 452. 42.  John L. Fulmer, “Analysis of Careers for Georgia Youth in Computer Occupations, 1971–76,” in Proceedings of the Eleventh SIGCPR Conference on Computer Personnel Research (New York: ACM, 1973), 78. 43.  Joan Greenbaum, In the Name of Efficiency: Management Theory and Shopfloor Practice in Data-Processing Work (Philadelphia: Temple University Press, 1979), 88; Dickmann and Lockwood, “Computer Personnel Research Group, 1966 Survey of Test Use in Computer Personnel Selection”; A. J. Biamonte, “Pre-

192  Notes

dicting Success in Programmer Training,” in Proceedings of the Second SIGCPR Conference on Computer Personnel Research (New York: ACM, 1964). 44. Jensen, How to Pass Computer Programmer Aptitude Tests, preface; Dickmann and Lockwood, “Computer Personnel Research Group, 1966 Survey of Test Use in Computer Personnel Selection,” 21. 45. Jensen, How to Pass Computer Programmer Aptitude Tests, preface. 46.  Dickmann and Lockwood, “Computer Personnel Research Group, 1966 Survey of Test Use in Computer Personnel Selection,” 20; W. J. McNamara, “The Selection of Computer Personnel: Past, Present, Future,” in Proceedings of the Fifth SIGCPR Conference on Computer Personnel Research (New York: ACM, 1967), 53. 47.  McNamara, “The Selection of Computer Personnel: Past, Present, Future,” 53–54. IBM had experimented with a verbal section in 1965 but felt it did not add to the predictive power of the test. 48.  Ibid., 53. 49.  “Computers: The Career of the Future,” London Times, June 17, 1969, 22. 50.  Dickmann and Lockwood, “Computer Personnel Research Group, 1966 Survey of Test Use in Computer Personnel Selection,” 19. 51.  McNamara, “The Selection of Computer Personnel: Past, Present, Future,” 54. 52.  Dickmann and Lockwood, “Computer Personnel Research Group, 1966 Survey of Test Use in Computer Personnel Selection,” 24. 53.  For example, Jacobs, “Cognitive Predictors of Success in Computer Programmer Training.” “Experienced programmers working at [the U.S. National Center for Atmospheric Research] were rated according to their performance and were given a battery of tests, most of which emphasized mathematical ability and logical thinking. The discouraging result of this unpublished study was that the excellent, the most highly-rated, programmers showed a very wide range of test scores.” Jeanne C. Adams, “Discussion of Jacobs Paper,” in Proceedings of the Eleventh SIGCPR Conference on Computer Personnel Research (New York: ACM 1973), 112. 54.  Menkhaus, “EDP: Nice Work If You Can Get It,” 43. 55.  Ann Hardy, interview by Janet Abbate, July 15, 2002. 56.  Kathy Humphry, interview by Janet Abbate, September 17, 2001. 57.  For example, Mary Coombs, who had a degree in French, was selected as a LEO programmer at Lyons after passing its aptitude test in 1953. Betty Cooper, a Lyons accounting clerk with no college education, joined Coombs after taking the same aptitude test in 1954. Diane Wray, a clerk at a UK electricity board with no college degree, passed an aptitude test and was promoted to a programming job in 1967. Mary Coombs, interview by Janet Abbate, September 25, 2001; Betty Cooper, interview by Janet Abbate, September 14, 2001; Diane Wray, interview by Janet Abbate, April 5, 2001. 58. Theodore C. Willoughby, William H. Enneis, Jean M. Palormo, and Wayne W. Sorenson, “Panel: Current Perspectives on Selection Testing,” in Proceedings

Notes  193

of the Ninth SIGCPR Conference on Computer Personnel Research (New York: ACM, 1971), 58. 59.  Theodor D. Sterling, M. Lichstein, F. Scarpino, D. Stuebing, and William Stuebing, “Professional Computer Work for the Blind,” Communications of the ACM 7, no. 4 (1964): 230. 60.  Lucy Slater, interview by Janet Abbate, April 9, 2001. 61.  For example, in a survey of job ads from 1952 to 1962, only five out of twenty-eight that asked for math training made this distinction, and four were for research facilities rather than industry (the fifth was Space Technology Laboratories of TRW). Employers who did make a point of specifying applied math also tended to list particular skills: “Applied Mathematicians familiar with creating numerical methods for solving ordinary and partial differential equations on digital computers” (1954); “research in mathematical analysis and simulation of complex systems” (1961); “Applied Mathematics and Numerical Analysis” (1961). But these exceptions highlight how vague the requirement for math was in the majority of ads, which gave no indication of what specific type of math knowledge, if any, the job would actually draw on. 62.  This curricular emphasis reflected a strong status difference between pure and applied math. For example, computer pioneer Jean Sammet recalled that when she was a graduate student in math at the University of Illinois from 1948 to 1951, she and her fellow math students felt “contempt” at the thought of working with the university’s computers, which they equated with routine drudgery: “We considered that sort of one step above garbage collecting. That was practical stuff. Not only was it dull, we felt, but demeaning to pure mathematicians.” Jean Sammet, interview by Janet Abbate, August 29, 2001. 63.  “Hence, a significant fraction of the applied mathematical training available in this country today is being administered by non-academic institutions under industrial sponsorship.” National Research Council, Report on a Survey on Training and Research in Applied Mathematics (Washington, DC: National Academies Press, 1956), 41. 64.  Bruce H. Barnes and Malcolm H. Gotterer, “Attributes of Computer Professionals,” in Proceedings of the Ninth SIGCPR Conference on Computer Personnel Research (New York: ACM, 1971), 174. 65.  Display ads, New York Times, August 22, 1954, F11. 66.  National Academy of Sciences, “Climbing the Ladder: An Update on the Status of Doctoral Women Scientists and Engineers,” 1983, table 1.1. For comparison, women earned 13 percent of physical science degrees in 1960, 25 percent of biology degrees, and less than 1 percent of engineering degrees. 67.  Dallis Perry and William Cannon, “Vocational Interests of Female Programmers,” Journal of Applied Psychology 52, no. 1 (1968): 31–32. 68.  Carol Shanesy, interview by Janet Abbate, August 1, 2001. 69.  David Alan Grier, When Computers Were Human (Princeton: Princeton University Press, 2005). 70.  Elsie Shutt, interview by Janet Abbate, February 9, 2001.

194  Notes

71.  Mary Kircher, interview by Janet Abbate, April 3, 2002. 72.  U.S. Department of Labor, Women’s Bureau, “Employment Opportunities for Women Mathematicians and Statisticians,” 6. 73.  Display ads, New York Times, March 6, 1960, F19, ellipsis in original. 74.  Display ads, Chicago Daily Tribune, September 4, 1955, A10; display ads, Los Angeles Times, September 1, 1959, C2; display ads, New York Times, September 4, 1960, 112. 75.  Display ads, New York Times, August 29, 1954, F9. 76.  Display ads, Los Angeles Times, September 7, 1961, B18. 77.  For a description of analog computing, see Martin Campbell-Kelly and William Aspray, Computer: A History of the Information Machine (New York: Basic Books, 1996), 60–63. 78.  Display ads, Chicago Daily Tribune, March 4, 1956, B5. 79.  Display ads, Los Angeles Times, September 7, 1958, H11. 80. Grier, “The ENIAC, the Verb ‘to Program’ and the Emergence of Digital Computers.” He recounts how the verb to program (and by extension, the job title of programmer) was chosen by ENIAC creator John Mauchly to convey status. In hand calculation, which was one obvious model for computer programming, the verb plan was used to describe laying out the steps of a calculation. Programming was a term drawn from the more prestigious field of electronics, and Mauchly hoped that appropriating this term would lend some gloss to his new field. 81.  Joyce Currie Little, interview by Janet Abbate, September 9, 2002. 82. See Oldenziel, Making Technology Masculine; Sally L. Hacker, Pleasure, Power and Technology: Some Tales of Gender, Engineering, and the Cooperative Workplace (Boston: Unwin Hyman, 1989). 83.  U.S. Department of Labor, Bureau of Labor Statistics, “U.S. Working Women: A Databook,” 1977, table 8. 84.  Clare Dover, “The Under-Employed Sex,” New Scientist, February 29, 1968, 20. Lisle stockings were thick cotton hose in dull colors. They were used widely during World War II when nylon was unavailable and were popularly seen as practical but ugly. Brogues are rugged walking shoes. Both images are used to imply that practicality is incompatible with femininity. 85.  H. W. Gearing, “Selection and Training of Programmers: A Business User’s Approach,” Computer Journal 2, no. 3 (1959): 108, emphasis in original. 86.  Robert N. Reinstedt, “Summary Report on Nationwide Testing Effort,” Paper presented at the Proceedings of the Second SIGCPR Conference on Computer Personnel Research, 1964, 4–5. 87.  Paul Armer, “Problems in Administrative Leadership in the Computer Field,” Paper presented at the Proceedings of the Second SIGCPR Conference on Computer Personnel Research, 1964, 95–97, emphasis in original. 88.  Booth, “Training and Development Plans and Results at Mobil Data Services Ltd.,” 107. The fourth was “computer concepts.” 89.  See Hoos, “When the Computer Takes Over the Office,” 104.

Notes  195

90.  Display ads, Los Angeles Times, September 4,1960, C3. 91. Robert G. Van Ness, Principles of Data Processing with Computers (Elmhurst, IL: Business Press, 1966), 224. A similar point is made by Dickmann and Lockwood, “Computer Personnel Research Group, 1966 Survey of Test Use in Computer Personnel Selection,.” 19, see also 25. Interviews with women about their career paths suggest the same trend, and Jean Sammet made that point explicitly. Jean Sammet, interview by Janet Abbate, August 29, 2001. 92. Allan, “The Selection and Training of Computer Personnel in the United Kingdom,” 73; Paul D. Oyer, “An Approach to Computer Personnel Evaluation,” in Proceedings of the Seventh SIGCPR Conference on Computer Personnel Research (New York: ACM, 1969), 104–105. 93. Van Ness gives several examples of how companies that were converting from tabulators to computers reclassified tab operators as programmers and gave them commensurate salary increases. Van Ness, Principles of Data Processing with Computers, 143, 214; see also Menkhaus, “EDP: Nice Work If You Can Get It,” 43–44. The Bureau of Labor Statistics reported in 1974 that this was still a common practice. U.S. Department of Labor, Bureau of Labor Statistics, “Computer Manpower Outlook,” 1974, 20. But Marie Hicks, “Meritocracy and Feminization in Conflict: Computerization in the British Government,” in Gender Codes: Why Women Are Leaving Computing, ed. Thomas Misa (Hoboken, NJ: Wiley, 2010), points out that women in the British civil service were blocked from this path to advancement. 94.  Betty Cooper, interview by Janet Abbate, September 14, 2001. 95. Angel Kwolek-Folland, Incorporating Women: A History of Women and Business in the United States (New York: Twayne, 1998; Simon & Schuster Macmillan, 2002). 96. Campbell-Kelly and Aspray observe, “Indeed, applications programming was often located within the marketing division of the computer manufacturers.” Campbell-Kelly and Aspray, Computer: A History of the Information Machine, 192. 97.  Display ads, New York Times, March 6, 1960, S5. 98.  Ibid., F14. 99.  Jean Jennings Bartik, interview by Janet Abbate, August 3, 2001. 100.  Ann Hardy, interview by Janet Abbate, July 15, 2002. It was not literally true that IBM had no female sales representatives or executives. The company hired its first female sales representative in 1936, and one of the early systems service representatives, Ruth Leach Amonette, became the company’s first female vice president in 1943. IBM Archives, “A Selective Chronology of IBM Women in Technology,” n.d., http://www-03.ibm.com/ibm/history/witexhibit/wit_timeline.html. 101. See Kanter’s classic study on women in business. Rosabeth Moss Kanter, Men and Women of the Corporation (New York: BasicBooks, 1977, rev. 1993). Rockmael comments on glass ceilings in programming specifically. Valerie Rockmael, “The Woman Programmer: A Subjective Reflection,” Datamation (January 1963): 41.

196  Notes

102.  Hicks, “Meritocracy and Feminization in Conflict: Computerization in the British Government,” 101. 103.  Joseph C. Hoyle and Richard D. Arvey, “Development of Behaviorally Based Rating Scales,” in Proceedings of the Tenth SIGCPR Conference on Computer Personnel Research (New York: ACM, 1972), 91. 104.  Oyer, “An Approach to Computer Personnel Evaluation,” 103–105. 105.  Van Ness, Principles of Data Processing with Computers, 215. 106. Jean Sammet, interview by Janet Abbate, August 29, 2001. Datamation noted in 1963 that “Newspaper and magazine ads are generally oriented toward men, although women applicants are frequently accepted. In the majority of cases however, there is no statement in the advertisement indicating this fact.” Rockmael, “The Woman Programmer: A Subjective Reflection,” 41. 107.  U.S. Department of Labor, Women’s Bureau, “Employment Opportunities for Women Mathematicians and Statisticians,” 6. 108.  International Business Machines, “My Fair Ladies,” 1957. 109.  Dover, “The Under-Employed Sex,” 19. 110.  Ibid., 19–20. 111.  Betty Campbell, interview by Janet Abbate, February 13, 2001. 112. George Fischer, Your Career in Computers (New York: Meredith Press, 1968), 16. A male RAND consultant used the household metaphor in reverse. He compared recruiting programmers to choosing a wife, arguing that “we want to know if she will be successful and happy as a wife and mother as we see the job of ‘programming’ a family to be.” Reinstedt, “Summary Report on Nationwide Testing Effort,” 1. 113.  Grace Murray Hopper, “Interview by Angeline Pantages,” Computer History Museum Oral History Collection, 1980, 27. 114.  Henry S. Tropp, “A Perspective on SAGE: Discussion,” Annals of the History of Computing 5, no. 4 (1983): 386. 115.  Van Ness, Principles of Data Processing with Computers, 225. 116.  Maureen Epstein, “Computer Women,” Guardian, January 31 1964, quoted in Tom Lloyd, “Steve Shirley and F International,” in Dinosaur & Co.: Studies in Corporate Evolution (London: Routledge & Kegan Paul, 1984), 66. 117.  Rockmael, “The Woman Programmer: A Subjective Reflection,” 41. 118.  As Margery Davies has documented, before 1900 clerical work was a man’s job with a path to management, but in the early twentieth century it became a dead-end, largely female job. Margery W. Davies, Woman’s Place Is at the Typewriter: Office Work and Office Workers, 1870–1930 (Philadelphia: Temple University Press, 1982). 119.  Perry and Cannon, “Vocational Interests of Computer Programmers,” 30. 120.  U.S. Department of Labor, Women’s Bureau, “Employment Opportunities for Women Mathematicians and Statisticians,” 28. A researcher at New York University tried to formalize this puzzle-solving skill in 1964 by introducing a new

Notes  197

programmer aptitude test, arguing that “programming is essentially a problemsolving task which should be measured by a problem-solving device.” Biamonte, “Predicting Success in Programmer Training,” 10. The test was never widely adopted. 121.  Margaret Marrs, interview by Janet Abbate, April 9, 2001. 122.  John Salerno, “Letter to the Editor,” Communications of the ACM 2, no. 8 (1959): 4–5. 123.  Hoos, “When the Computer Takes Over the Office,” 104, emphasis in original. 124. George Fischer, Your Career in Computers (New York: Meredith Press, 1968), 16. 125.  Ida Rhodes, “Interview by Henry Tropp,” March 21, 1973, Computer Oral History Collection, Smithsonian Institution National Museum of American History, 30, brackets in original. 126.  Grace Murray Hopper, “‘Problem L’ Staff,” Grace Murray Hopper Collection 1944–1946, Smithsonian Institution Research Information System (SIRIS), #324. 127.  Kathleen Broome Williams, Grace Hopper: Admiral of the Cyber Sea (Annapolis: Naval Institute Press, 2004), 89. Specifically, Hopper wanted to include a compiler, which she had invented. A layette is a set of clothes for a newborn baby. 128. Howard Aiken, “Interview by Henry Tropp and I. B. Cohen,” February 26–27, 1973, Computer Oral History Collection, Smithsonian Institution National Museum of American History, 55. Aiken made this remark after describing how the Harvard group sometimes relied on Hopper to supply a pocket mirror—something the men apparently refused to carry, even though they used it on a regular basis to help troubleshoot the machine. As Aiken explained, “The cams [in the Mark I] were somewhat difficult to see, and when cams were in trouble, Grace would come out and pull her mirror out of her pocketbook and stick [it] in front of the cams and look for sparks.” 129.  For nontechnical characteristics that were valued by managers, see Robert A. Dickmann, “A Programmer Appraisal Instrument,” Paper presented at the Proceedings of the Second SIGCPR Conference on Computer Personnel Research, 1964. 130.  Marge Devaney, interview by Janet Abbate, April 4, 2002 131.  Sylvia Ann Hewlett, Carolyn Buck Luce, Lisa J. Servon, Laura Scherbin, Peggy Shiller, and Eytan Sosnovich, “The Athena Factor: Reversing the Brain Drain in Science, Engineering, and Technology,” Harvard Business Review (2008): 27. Thanks to an anonymous reviewer for this reference.

Chapter 3 1.  Hugh Robinson, Pat Hall, Fiona Hovenden, and Janet Rachel, “Postmodern Software Development,” Computer Journal 41, no. 6 (1998): 364. Historian Thomas Haigh has been one of the most astute critics of the “crisis” narrative.

198  Notes

Thomas Haigh, “‘Crisis, What Crisis?’ Reconsidering the Software Crisis of the 1960s and the Origins of Software Engineering,” Paper presented at the Second Inventing Europe / Tensions of Europe Conference, Sofia, Bulgaria, 2010. 2.  Marvin Minsky, “Afterword,” in Vernor Vinge, True Names and the Opening of the Cyberspace Frontier, ed. James Frenkel, 331–352 (New York: Tor Books, 2001). 3. Some historians have implied that Hopper coined the term automatic programming See, for example, Paul E. Ceruzzi, A History of Modern Computing (Cambridge: MIT Press, 1998), 85; Kurt W. Beyer, Grace Hopper and the Invention of the Information Age (Cambridge: MIT Press, 2009), 221). She later disavowed this, and in fact she rarely used the phrase. The term may have been less popular in the United Kingdom. Maurice V. Wilkes, David J. Wheeler, and Stanley Gill did not use the term in the first edition of their programming textbook, The Preparation of Programs for an Electronic Digital Computer (Reading, MA: Addison-Wesley, 1951), and used it only cautiously in the 1957 edition. The phrase automatic programming had been used at least since 1944 in a different sense to refer simply to programming an automatic digital computer. See, for example, J. Presper Eckert’s January 1944 “Disclosure of Magnetic Calculating Machine,” reprinted in Nicholas Metropolis, Jack Howlett, and Gian-Carlo Rota, eds., A History of Computing in the Twentieth Century (New York: Academic Press, 1980), 538. 4.  Quoted in Michael S. Mahoney, “Software: The Self-Programming Machine,” in From 0 to 1: An Authoritative History of Modern Computing, ed. Atsushi Akera and Rik Nebeker (New York: Oxford University Press, 2002), 93. 5.  Grace Murray Hopper, “The Education of a Computer,” in Proceedings of the 1952 ACM National Meeting (Pittsburgh: ACM, 1952), 243. 6. U.S. Department of Labor, Bureau of Labor Statistics, “Occupational Outlook Handbook: Computer Software Engineers and Computer Programmers,” 2010–2011. 7.  Wilkes, Wheeler, and Gill, The Preparation of Programs for an Electronic Digital Computer (1st ed., 1951), 38. Maintaining code proved to be another unexpected time sink, but this issue was not as salient at first, since many scientific programs were intended to be used for only a single problem. 8.  All modern computers now include floating-point hardware. A standard measure of computer performance is flops (floating-point operations per second). 9.  John Backus, head of the FORTRAN team, recalled that for programmers in the early 1950s, “Much of their effort was devoted to overcoming the difficulties created by the computers of that era: the lack of index registers, the lack of builtin floating point operations, restricted instruction sets (which might have AND but not OR, for example), and primitive input-output arrangements. Given the nature of computers, the services which ‘automatic programming’ performed for the programmer were concerned with overcoming the machine’s shortcomings.” J. W. Backus, “The History of FORTRAN I, II, and III,” IEEE Annals of the History of Computing 1, no. 1 (1979): 21.

Notes  199

10.  Hopper, “The Education of a Computer,” 243; Beyer, Grace Hopper and the Invention of the Information Age. 11.  Maurice V. Wilkes, “Early Programming Developments in Cambridge,” in A History of Computing in the Twentieth Century, ed. Nicholas Metropolis, Jack Howlett, and Gian-Carlo Rota (New York: Academic Press, 1980), 498–499). The input system for EDSAC, called the “initial orders,” read in the subroutines and put them in memory as a single program, using temporary addresses for the subroutine calls. Then another program called the “assembly subroutine” went through the program and replaced the temporary addresses with absolute memory addresses. Although Wilkes, Wheeler, and Gill became associated with the idea of subroutines, the inventor of this technique is a matter of some dispute. Hopper (1952) claimed to have learned about subroutines from Howard Aiken in 1946, and Eckert and Mauchly claimed to have had the idea in mind even earlier when they designed the ENIAC. J. Presper Eckert, Jr., “The ENIAC,” in A History of Computing in the Twentieth Century, ed. Nicholas Metropolis, Jack Howlett, and Gian-Carlo Rota (New York: Academic Press, 1980), 527. Reusing successful code is, arguably, a common-sense notion that probably occurred to multiple people independently, as Knuth and Pardo seem to imply. Donald E. Knuth and Luis Trabb Pardo, “The Early Development of Programming Languages,” in A History of Computing in the Twentieth Century, ed. Nicholas Metropolis, Jack Howlett, and Gian-Carlo Rota (New York: Academic Press, 1980), 233). 12. Knuth and Pardo, “The Early Development of Programming Languages,” 213; Grace Murray Hopper, “Compiling Routines,” Computers and Automation 2 (1953): 1252. 13. Beyer, Grace Hopper and the Invention of the Information Age, 236. 14.  J. W. Backus, R. J. Beeber, S. Best, R. Goldberg, L. M. Haibt, H. L. Herrick, R. A. Nelson, et al., “The FORTRAN Automatic Coding System,” Paper presented at the IRE-AIEE-ACM Western Joint Computer Conference, 1957, 188. 15.  Lois Haibt, interview by Janet Abbate, August 2, 2001. See also Backus, “The History of FORTRAN I, II, and III,” 24. 16. Knuth and Pardo, “The Early Development of Programming Languages,” 266. 17. Grace Murray Hopper, “Interview by Angeline Pantages,” 1980, Hopper (Grace) Oral History, Computer History Museum Oral History Collection, 8–9. Ceruzzi sees Holberton’s sorting routine for UNIVAC (1952) as a major software milestone since sorting was perhaps the most important task of business computers at that time. Ceruzzi, A History of Modern Computing, 89–90. 18. John Waite, “Editing Generators,” in Symposium on Automatic Programming for Digital Computers, ed. U.S. Office of Naval Research (Washington, DC: Office of Naval Research, 1954), 23–24. 19.  John Backus, “Programming in America in the 1950s: Some Personal Impressions,” in A History of Computing in the Twentieth Century, ed. Nicholas Metropolis, Jack Howlett, and Gian-Carlo Rota (New York: Academic Press, 1980), 132; see also Lois Haibt, interview by Janet Abbate, August 2, 2001.

200  Notes

20.  R. W. Bemer, “A View of the History of COBOL,” Honeywell Computer Journal 5, no. 3 (1971): 131; Jean Sammet, “The Early History of COBOL,” in History of Programming Languages, ed. R. L. Wexelblat (New York: Academic Press, 1981), 209. 21.  Quoted in James E. Tomayko, “The Case against Automatic Programming,” Annals of the History of Computing 11, no. 4 (1989): 323; see also Beyer, Grace Hopper and the Invention of the Information Age, 241. Although Grosch placed himself on the “neanderthal” side, he was not absolutely opposed to the new techniques. He was a good friend of Hopper, and he oversaw the creation of the first compiler for the IBM 701. Beyer, Grace Hopper and the Invention of the Information Age; Herbert R. J. Grosch, Computer: Bit Slices from a Life (Novato, CA: Third Millennium Books, 1991), 171. 22. Tomayko, “The Case against Automatic Programming.” See also Martin Campbell-Kelly and William Aspray, Computer: A History of the Information Machine (New York: Basic Books, 1996), 187–188. 23. John Backus, quoted in Tomayko, “The Case against Automatic Programming,” 323. Backus, “Programming in America in the 1950s: Some Personal Impressions,” 127. 24.  As Wilkes, Wheeler, and Gill note in the “Automatic Programming” section of their 1957 second edition, “The controversy may now be said to have died down and it is generally agreed that the work of programmers can be much facilitated by the use of such techniques.” Wilkes, Wheeler, and Gill, The Preparation of Programs for an Electronic Digital Computer (2nd ed., 1957), 126. 25.  Computer scientists Don Knuth and Luis Pardo describe her “barnstorming throughout the country, significantly helping to accelerate the rate of progress.” Knuth and Pardo, “The Early Development of Programming Languages,” 236. Campbell-Kelly and Aspray state that “Probably no one did more to change the conservative culture of 1950s programming than Grace Hopper.” Campbell-Kelly and Aspray, Computer: A History of the Information Machine, 187. 26.  Hopper, “The Education of a Computer,” 243. 27.  Ibid., 249. 28.  Ibid., 243. 29.  Grace Murray Hopper, “Automatic Programming—Definitions,” in Symposium on Automatic Programming for Digital Computers, ed. U.S. Office of Naval Research (Washington, DC: Office of Naval Research, 1954), 1. 30. Ibid. 31. Campbell-Kelly maintains that this distinction had no real basis and was abandoned relatively quickly. By the early 1970s, “the arbitrary distinction between senior and junior programmers and between programmers and coders was lost. Indeed, the term ‘coder’ fell out of use.” Martin Campbell-Kelly, “The Development and Structure of the International Software Industry, 1950–1990,” Business and Economic History 24, no. 2 (1995): 70. 32.  Hopper, “Automatic Programming—Definitions,” 1–2, emphasis added.

Notes  201

33.  Martin Greenberger, ed. Computers and the World of the Future (Cambridge: MIT Press,1962), 272. 34. Wilkes, Wheeler, and Gill, The Preparation of Programs for an Electronic Digital Computer (2nd ed., 1957, 90–91. 35.  Nora B. Moser, “Compiler Method of Automatic Programming,” in Symposium on Automatic Programming for Digital Computers, ed. U.S. Office of Naval Research (Washington, DC: Office of Naval Research, 1954), 20–21. Moser referred to system programmers as “persons comparable to engineers” (21). 36.  Grace Murray Hopper, “Summary,” in Symposium on Automatic Programming for Digital Computers, ed. U.S. Office of Naval Research (Washington, DC: Office of Naval Research, 1954), 148, 149. 37. Wilkes, Wheeler, and Gill, The Preparation of Programs for an Electronic Digital Computer (2nd ed., 1957). 38.  Quoted in Knuth and Pardo, “The Early Development of Programming Languages,” 213. Similarly, Wilkes, Wheeler, and Gill noted in 1957 that “There has been much controversy over the value of the methods” between “enthusiasts” and “those who have felt that its advantages were more apparent than real.” Wilkes, Wheeler, and Gill, The Preparation of Programs for an Electronic Digital Computer (2nd ed., 1957), 126. R. D. Richtmyer at the Atomic Energy Commission Computing Facility at New York University described automatic programming efforts in 1956 as “noble experiments” that “should be encouraged” but criticized their boosters as uncompromising zealots who “greet any suggestion that their system may not be a cure-all with a condescending smile.” Quoted in Tomayko, “The Case against Automatic Programming,” 324. 39. Stephanie Shirley, interview by Janet Abbate, April 20, 2001. Joyce Currie Little, who began programming in 1957 at Convair, recalled similar predictions: “When FORTRAN first came out, you would hear people saying, ‘We don’t need programmers anymore. . . . Every engineer’s going to program for themselves.’ . . . I heard that again when COBOL came out: ‘We’re not going to need programmers anymore!’” Joyce Currie Little, interview by Janet Abbate, September 9, 2002. 40.  Remington Rand ad, “Now . . . Univac Tells Itself What to Do!,” Chicago Daily Tribune, June 10, 1955, C6. 41.  Bendix Computer Division, “Bendix G-15 General Purpose Digital Computer,” Bendix Corporation, Los Angeles, 1955, 3. 42. See, e.g., Harry Braverman, Labor and Monopoly Capital (New York: Monthly Review Press, 1974); David Noble, Forces of Production: A Social History of Industrial Automation (New York: Knopf, 1984). 43.  Computer manufacturers were not notably sympathetic to displaced workers. In December 1955, a group of social scientists and computer industry representatives held a conference at Yale University to discuss the social effects of automation. The experts were concerned mainly with avoiding unrest from male factory workers; female workers were dismissed as unimportant. As the New York Times reported, “Bureau of Labor Statistics said that the new electronic computors [sic] had eliminated many jobs and that those hardest hit were young women in rou-

202  Notes

tine clerical work. This did not impress other members of the panel. They insisted that the girls were ‘much more docile’ than factory workers and were ‘only waiting to get married.’” Homer Bigart, “Experts Divided over Automation,” New York Times, December 28, 1955. 44.  Philip Kraft, Programmers and Managers (New York: Springer, 1977); Joan Greenbaum, In the Name of Efficiency: Management Theory and Shopfloor Practice in Data-Processing Work (Philadelphia: Temple University Press, 1979). 45.  Mahoney argues that the practical success of compilers and other 1950s innovations “emboldened people to think about programming languages and programming environments that would obviate the need for programmers in the long run and in the meantime bring them under increasing[ly] effective managerial control.” Mahoney, “Software: The Self-Programming Machine,” 93. Referencing Mahoney’s interpretation, Paul Ceruzzi states that “The goal for proponents of Automatic Programming was to develop for software what Henry Ford had developed for automobile production, a system of interchangeable parts.” Ceruzzi, A History of Modern Computing, 85–86. 46.  In a 1970 article, data processing manager M. H. Schwartz compared programmers to pilots and argued that, for both, automation increased the need for skill because they needed to learn how to use the new tools and because they were expected to accomplish more now that they had them. Joseph F. Cunningham and M. H. Schwartz, “A Dialogue on Managers, Data Processing Managers, and Computer Programming Managers,” in On the Management of Computer Programming, ed. George F. Weinwurm (Philadelphia: Auerbach, 1970), 226. The Laning-Zierler compiler that had been developed at MIT for the Whirlwind/ SAGE computer was rejected by some of the engineers and managers on that project, who thought that compilers were “dangerous” because they allowed programmers to manipulate computer memory in new ways. Herb Benington, who oversaw production of SAGE software, confirmed that “symbolic addressing . . . would have been heresy in Whirlwind.” Benington feared such tools gave programmers too much discretion: “We thought that some of those tools were dangerous because they couldn’t be well disciplined.” Instead, he preferred management tools for “controlling of the team” and the individual programmer, so that “you could find out if that individual was playing the game wrong and punish the person.” Henry S. Tropp, “A Perspective on SAGE: Discussion,” Annals of the History of Computing 5, no. 4 (1983): 386–387. Judy Clapp, who joined the Whirlwind programming team in 1952, recalled similar earlier reactions to assemblers. “I was working with a group of engineers who said, ‘That’s dangerous! We won’t do it!’” According to Clapp, the engineers distrusted symbolic addressing and preferred having “total control” over where data was stored on the computer. Judy Clapp, interview by Janet Abbate, February 11, 2001. Although deskilling was not a major issue in the United States or United Kingdom, Michael A. Cusumano notes that the Japanese software industry moved closer to a deskilled factory model in the 1970s, which he attributes in part to a greater shortage of skilled programmers in Japan. Michael A. Cusumano, “Factory Concepts and Practices in Software Development,” IEEE Annals of the History of Computing 13, no. 1 (1991): 3–32.

Notes  203

47. Grace Murray Hopper, “Interview by Angeline Pantages,” 1980, Hopper (Grace) Oral History, Computing History Museum Oral History Collection, 33. 48.  Eugene H. Jacobs, “Letter to the Editor,” Communications of the ACM 2, no. 7 (1959): 6. 49.  Gerald M. Weinberg, The Psychology of Computer Programming (New York: Van Nostrand Reinhold, 1971), 5. 50.  For example, see Betty Snyder Holberton’s claim that “The professional programmer was afraid of job security.” Quoted in Kathleen Broome Williams, Grace Hopper: Admiral of the Cyber Sea (Annapolis: Naval Institute Press, 2004), 84. 51.  For example, Campbell-Kelly and Aspray argue that “many of the seasoned programmers of the 1950s were as reluctant to change their working methods as had been the hand weavers to adopt looms two hundred years earlier.” CampbellKelly and Aspray, Computer: A History of the Information Machine, 87. 52.  Backus, “Programming in America in the 1950s: Some Personal Impressions,” 127, 128. Although Backus was understandably frustrated that his efforts to develop high-level languages were resisted by his peers, he did not position himself as a theorist looking down disdainfully on programmers, as Ensmenger has suggested. Nathan Ensmenger, The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise (Cambridge: MIT Press, 2010), 91, 93, 151. Backus identified himself as a programmer and was just as apt to mock “the stuffiness of academia” as the “priesthood” of programmers. Backus, “The History of FORTRAN I, II, and III”; Backus, “Programming in America in the 1950s: Some Personal Impressions,” 126. 53.  Roy Goldfinger, “New York University Compiler System,” in Symposium on Automatic Programming for Digital Computers, ed. U.S. Office of Naval Research (Washington, DC: Office of Naval Research, 1954); Maurice V. Wilkes, “Software Engineering and Structured Programming,” IEEE Transactions on Software Engineering SE-2, no. 4 (1976): 274; S. Mamrak and J. M. Randal, “An Analysis of a Software Engineering Failure,” Computer Journal 20, no. 4 (1977): 316. 54.  Rudolph E. Hirsch, “Maximising the Productivity of Programmers,” Computer Weekly 15 (1973): 6. 55.  Campbell-Kelly and Aspray, Computer: A History of the Information Machine, 196. 56.  See, e.g., Maria Eloina Pelaez Valdez, “A Gift from Pandora’s Box: The Software Crisis,” Dissertation, University of Edinburgh, 1988. 57.  Haigh, ““Crisis, What Crisis?’ Reconsidering the Software Crisis of the 1960s and the Origins of Software Engineering.” 58.  Martin Campbell-Kelly, From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry (Cambridge: MIT Press, 2003), 94. CampbellKelly adds that “The proceedings of the [1968 NATO conference on software engineering] give a revealing glimpse of the nature of the debate—almost all the evidence was anecdotal, often in the form of compelling ‘war stories’ from leading software practitioners” (94). 59.  Robinson et al., “Postmodern Software Development,” 363.

204  Notes

60. Grace M. Hopper and John W. Mauchly, “The Influence of Programming Techniques on the Design of Computers,” Proceedings of the IRE 41, no. 10 (1953): 1251. 61. Nathan Ensmenger, “Making Programming Masculine,” in Gender Codes: Why Women Are Leaving Computing, ed. Thomas Misa (Hoboken, NJ: Wiley, 2010), 118. 62.  The Economist, April 8, 1967, 162. 63. U.S. Department of Commerce, Bureau of the Census, Statistical Abstract of the United States (Washington, DC: U.S. Government Printing Office, 1974), tables 571, 581. The 1969 salary figures are comparable to a 1969 EDP industry survey, which found that average salaries (combining both sexes) ranged from $7,600 for junior programmers to $12,200 for lead systems analyst or programmers. Business Automation, “Nation-Wide Weekly Salary Data for All EDP Jobs,” Business Automation (June 1969): 48–59. I based annual salary estimates on their reported weekly salaries of $152 and $244, respectively. 64. This is based on U.S. Census figures for 1970, which count 51,000 female “computer specialists,” 20 percent of the total of 258,000. U.S. Department of Commerce, Bureau of the Census, Statistical Abstract of the United States (Washington, DC: U.S. Government Printing Office, 1975), table 589. I have found no comparable figures for the United Kingdom. 65.  The U.S. Department of Labor advised women in 1956 that they would be expected to have a B.A. degree or higher for programming jobs and that female mathematicians generally needed higher qualifications than men to get high-level positions. U.S. Department of Labor, Women’s Bureau, “Employment Opportunities for Women Mathematicians and Statisticians” (1956), 6–7. Paula Hawthorn, who received a B.A. in math from the University of Houston in 1966, recalled blatant double standards for programming jobs: “Texaco was hiring math majors: women who had A’s in math and men who had B’s and above! That was very explicit.” Paula Hawthorn, interview by Janet Abbate, July 5, 2002. 66.  Marie Hicks, “Meritocracy and Feminization in Conflict: Computerization in the British Government,” in Gender Codes: Why Women Are Leaving Computing, ed. Thomas Misa (Hoboken, NJ: Wiley, 2010). 67.  Blacks were even more underrepresented than women. In 1970, only 3 percent of computer specialists in the United States were black, compared to 11 percent of the total population, and there is little evidence that blacks were recruited by employers to solve the “shortage.” U.S. Department of Commerce, Bureau of the Census, Statistical Abstract of the United States (Washington, DC: U.S. Government Printing Office, 1974), table 571. The 1968 training program mentioned in chapter 2, in which General Electric taught a group of black high-school dropouts to be programmers, was the only instance I found of employers specifically recruiting from the black community. Bernstein, “A Programmmer Training Project.” 68.  Michael S. Mahoney, “The Histories of Computing(s),” Interdisciplinary Science Reviews 30, no. 2 (2005): 119–133.

Notes  205

69.  Campbell-Kelly and Aspray, Computer: A History of the Information Machine, 196, 200. 70. Campbell-Kelly, From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry, 67, 94. 71.  P. Naur and B. Randell, eds., Software Engineering: Report of a Conference Sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968 (Brussels: NATO Scientific Affairs Division,1969), 121. 72. Cunningham and Schwartz, “A Dialogue on Managers, Data Processing Managers, and Computer Programming Managers,” 222. 73. Campbell-Kelly, From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry, 91. Historian Paul Ceruzzi notes, “more recent studies of software expenditures seem to conclude that over the years the ratio has remained more or less constant” rather than rising sharply. Ceruzzi, A History of Modern Computing, 82. Frank’s 1968 argument was not unprecedented. In 1953, John Backus had made the case for his Speedcoding system by claiming that programming accounted for 50 to 75 percent of computing costs. J. W. Backus, “The IBM 701 Speedcoding System,” Journal of the ACM 1, no. 1 (1953): 4. 74.  Werner Frank, “The History of Myth #1,” Datamation (May 1983): 252–263. 75. Frederick P. Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering,” Computer 20, no. 4 (1987): 11. 76. Ensmenger, The Computer Boys Take Over, 147. 77.  Ibid.,19, 146, 149, 158, 159. 78.  Carl W. Clewlow, “Managing Computer Programming in the Federal Government,” in On the Management of Computer Programming, ed. George F. Weinwurm (Philadelphia: Auerbach, 1970), 32. 79.  Dick H. Brandon, “The Economics of Computer Programming,” in On the Management of Computer Programming, ed. George F. Weinwurm (Philadelphia: Auerbach, 1970), 8,. 80.  Ibid., 9. 81. Ibid. 82. Cunningham and Schwartz, “A Dialogue on Managers, Data Processing Managers, and Computer Programming Managers,” 220. 83. Ibid. 84. Carl H. Reynolds, “What’s Wrong with Computer Programming Management?,” in On the Management of Computer Programming, ed. George F. Weinwurm (Philadelphia: Auerbach, 1970), 42. 85.  Carl H. Reynolds, “Notes on Estimating and Other Science Fiction,” Computer Usage Company, 1967, 2. 86.  George F. Weinwurm, ed., On the Management of Computer Programming (Philadelphia: Auerbach,1970), ix, emphasis in original. 87. Ibid. 88.  Ibid., xvi.

206  Notes

89. Frederick P. Brooks, The Mythical Man-Month: Essays on Software Engineering (Reading, MA: Addison-Wesley, 1975), 14. 90. Weinberg, The Psychology of Computer Programming, 61. 91.  Marlene Hazle, interview by Janet Abbate, February 11, 2001. 92.  Judy Clapp, interview by Janet Abbate, February 11, 2001. 93.  Barry Boehm, “Software Engineering—as It Is,” in ICSE ’79: Proceedings of the Fourth International Conference on Software Engineering (Piscataway, NJ: IEEE Press, 1979), 14. 94.  Dallis Perry and William Cannon, “Vocational Interests of Female Programmers,” Journal of Applied Psychology 52 (1968): 34; Dallis Perry and William Cannon, “Vocational Interests of Computer Programmers,” Journal of Applied Psychology 51, no. 1 (1967): 28–34. 95.  Robinson et al., “Postmodern Software Development,” 364. 96.  Naur and Randell, Software Engineering: Report of a Conference Sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968, 13. 97.  Ibid., 213–217. There were also several military and government observers. 98.  The Institution of Electrical Engineers, which was renamed the Institution of Engineering and Technology in 2006, publishes a journal called Software. The British Computer Society (BCS) has separate specialist groups for the theoretical and management aspects of software engineering—the Formal Aspects of Computing group and the Software Process Improvement Network, described as “of interest to software engineers and managers.” http://www.bcs.org/content/conWebDoc/1248, accessed February 28, 2011. 99.  See, e.g., Brooks, The Mythical Man-Month: Essays on Software Engineering, 46. For recent assertions of the merits of this view, see the interviews collected in Peter Seibel, Coders at Work: Reflections on the Craft of Programming (New York: Apress/Springer, 2009). 100. Weinwurm, On the Management of Computer Programming. 101.  Wilkes, “Software Engineering and Structured Programming,” 275. Wilkes argues that writing a program is similar to writing a paper because in neither case is the structure apparent at the beginning. He jokes, “When people say that structured programming is fine when you are writing a program for the second time, this is probably what they have in mind” (275). 102.  See, e.g., Brooks, The Mythical Man-Month: Essays on Software Engineering, 42, 46–47; C. A. R. Hoare, “Programming: Sorcery or Science?,” IEEE Software, April 1984, 5–16; and the comments cited in Nathan Ensmenger, “From ‘Black Art’ to Industrial Discipline: The Software Crisis and the Management of Programmers,” Dissertation, University of Pennsylvania, 2001, 17, 223. 103. Brooks, The Mythical Man-Month: Essays on Software Engineering, 32–34. Brooks admitted to “freely mix[ing] metaphors” (32). The inventor of the chief programmer team idea was Harlan Mills of IBM. 104.  Edsger W. Dijkstra, “Go to Statement Considered Harmful,” Communications of the ACM 11 (1968): 147–148; and Edsger W. Dijkstra, “Notes on Structured Programming,” Unpublished typescript, 1969.

Notes  207

105.  Dijkstra, “Notes on Structured Programming,” 2. 106.  Mary Shaw, “Prospects for an Engineering Discipline of Software,” IEEE Software, November 1990, 15–24; Mary Shaw, “Continuing Prospects for an Engineering Discipline of Software,” IEEE Software, November/December 2009, 64–67; Bashar Nuseibeh and Steve Easterbrook, “Requirements Engineering: A Roadmap,” in International Conference on Software Engineering: The Future of Software Engineering (New York: ACM, 2000), 35–46. 107. Institute of Electrical and Electronics Engineers (IEEE), IEEE Standard Glossary of Software Engineering Terminology: IEEE Standard 610.12-1990 (New York: IEEE, 1990), 67. 108.  Dijkstra, “Notes on Structured Programming,” 59. 109. Naur and Randell, Software Engineering: Report of a Conference Sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968, 17. 110. Brooks, The Mythical Man-Month: Essays on Software Engineering, 21. 111.  Laurie Keller, interview by Janet Abbate, September 26, 2001. Further support for the status function of the term engineer comes from the objections of traditional engineers, who feel that software engineers are usurping their privileges. ComputerWorld reported in 1994 that forty-eight U.S. states had “title laws” dating from the 1920s that barred anyone from calling themselves an engineer unless they were educated and licensed in one of thirty-six recognized engineering disciplines—which did not include software. A spokesperson for the National Society of Professional Engineers said that the laws were intended in part to “protect the credentials of registered professional engineers,” to which Ross Flaherty, president of the Association of Systems Management, objected, “I find it amazing that they want to corner the concept of engineers and engineering.” Julia King, “Engineers to IS: Drop that Title!” ComputerWorld, May 1994, 1. In 1999, a Canadian university was sued by two professional engineering societies for using the term software engineering. Fran Allen, Paula Hawthorn, and Barbara Simons, “Not Now, Not Like This: Why the ACM Council Does Not Support the Licensing of Software Engineers at This Time,” Communications of the ACM 43, no. 2 (2000): 29. 112.  Mahoney, “Software: The Self-Programming Machine,” 94, 99. 113.  Ibid., 98. 114. Kraft, Programmers and Managers, 148–149. 115.  Donald MacKenzie, Mechanizing Proof: Computing, Risk, and Trust (Cambridge: MIT Press, 2001), 39–40. 116.  Wilkes, “Software Engineering and Structured Programming,” 274. 117.  Martyn Clark, “State Support for the Expansion of UK University Computing in the 1950s,” IEEE Annals of the History of Computing 32, no. 1 (2010): 23; Peter C. Grindley, “The Future of the Software Industry in the United Kingdom: The Limits of Independent Production,” in The International Computer Software Industry, ed. David C. Mowery (Oxford: Oxford University Press, 1996), 226. 118.  As Albert Endres of IBM recalled, “At Garmisch, I already privately believed that the notion of a ‘software crisis’ was an exaggeration that theorists had constructed to justify their work.” Quoted in MacKenzie, Mechanizing Proof: Computing, Risk, and Trust, 37.

208  Notes

119. Alvey Committee, A Programme for Advanced Information Technology: The Report of the Alvey Committee (London: UK Department of Industry, 1982). The program was named after the chair of the committee that recommended it, John Alvey, who was senior director of technology at British Telecom. Grindley’s history of the Alvey program says that “Although software engineering did not receive the largest single share of funding, it was the key discipline; it embodied the main objectives of the program and was central to success in other areas.” Grindley, “The Future of the Software Industry in the United Kingdom: The Limits of Independent Production,” 219. 120. As stated in the 1982 Alvey Report that proposed the project, “The programme should be a collaborative effort between industry, the academic sector and other research organisations, in order to improve the harnessing of our technical strengths to industrial objectives.” Alvey Committee, A Programme for Advanced Information Technology: The Report of the Alvey Committee, Executive Summary, 2.3. 121. Anthony I. Wasserman, “Letter from the First Chairman,” Software Engineering Notes 15, no. 5 (1990): 1. 122.  For a list of participants, see Naur and Randell, Software Engineering: Report of a Conference Sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968, 13. 123. For Hopper’s Navy role, see Hopper, “Interview by Angeline Pantages,” 1980, Hopper (Grace) Oral History, Computer History Museum Oral History Collection, 5. Haigh also notes Hopper’s absence from Garmisch, although he interprets this as a failure to include business programming perspectives rather than a gender issue. Haigh, “‘Crisis, What Crisis?’ Reconsidering the Software Crisis of the 1960s and the Origins of Software Engineering,” 21. 124. Naur and Randell, Software Engineering: Report of a Conference Sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968, 14. 125.  Clare Dover, “The Under-Employed Sex,” New Scientist, February 1968, 20. 126.  A devaluation of the feminine may also explain the disdain with which many software engineers and computer scientists have regarded COBOL—a language that was designed with key inputs from several women and was meant for business data processing, which was the more people-oriented side of programming and had a higher proportion of women. See Sammet, “The Early History of COBOL,” 236–238; Ben Schneiderman, “The Relationship between COBOL and Computer Science,” IEEE Annals of the History of Computing 7, no. 4 (1985): 348, 351. 127.  David Alan Grier, “The ENIAC, the Verb ‘to Program’ and the Emergence of Digital Computers,” Annals of the History of Computing 18, no. 1 (1996): 51–55. 128.  Jean Jennings Bartik, interview by Janet Abbate, August 3, 2001. 129.  Judy Clapp, interview by Janet Abbate, February 11, 2001. 130.  Fran Allen, interview by Janet Abbate, August 2, 2001. 131.  For example, a recent report by the National Academy of Engineering found that young Americans see engineering as a largely masculine field that few girls regard as a potential career path. National Academy of Engineering, Committee

Notes  209

on Public Understanding of Engineering Messages, Changing the Conversation: Messages for Improving Public Understanding of Engineering (Washington, DC: National Academies Press, 2008), 58–59, 65. 132.  Ruzena Bajcsy, interview by Janet Abbate, July 9, 2002. 133.  Laurie Keller, interview by Janet Abbate, September 26, 2001. 134.  Susan Graham, interview by Janet Abbate, July 10, 2002. 135.  Naur and Randell, Software Engineering: Report of a Conference Sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968, 126. 136.  Shaw, “Prospects for an Engineering Discipline of Software,” 15. 137. Mary Shaw, “Software Engineering Education: A Roadmap,” in International Conference on Software Engineering: The Future of Software Engineering (New York: ACM, 2000), 376, 375. 138. “Spectral Lines: Learning from Software Failure,” IEEE Spectrum, 42, no. 9 (2005): 8. 139.  U.S. Department of Labor, Bureau of Labor, “Occupational Outlook Handbook: Computer Software Engineers and Computer Programmers,” 2010–2011, 2. 140.  Mahoney, “The Histories of Computing(s)”; Ceruzzi, A History of Modern Computing, 106. 141.  Bruce Barnes, “Interview by William Aspray,” September 26, 1990, Charles Babbage Institute, University of Minnesota, Minneapolis, DC, 19. Barnes estimated that the National Science Foundation supported about one quarter of the academic research on software engineering, the Department of Defense supported half, and other agencies supported the rest. 142.  Grindley, “The Future of the Software Industry in the United Kingdom: The Limits of Independent Production.” 143.  Campbell-Kelly, “The Development and Structure of the International Software Industry, 1950–1990,” 104. 144.  Paula Hawthorn, interview by Janet Abbate, July 5, 2002. 145.  Shaw, “Prospects for an Engineering Discipline of Software,” 16. Reassessing the state of the field in 2009, Shaw did not describe much progress toward becoming “engineering,” except in certain areas such as software architecture. Shaw, “Continuing Prospects for an Engineering Discipline of Software.” 146.  Mahoney, “Software: The Self-Programming Machine,” 94, 99. 147. MacKenzie, Mechanizing Proof: Computing, Risk, and Trust, 40. 148.  George F. Farris and Rene Cordero, “What Do We Know about Managing Scientists and Engineers: A Review of Recent Literature,” Center for Innovation Management Studies, North Carolina State University, 2002, 12. 149. Ibid. 150.  Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering,” 11, 18. 151.  W. Wayt Gibbs, “Software’s Chronic Crisis,” Scientific American (September 1994): 86.

210  Notes

152. James Bach, “Enough about Process: What We Need Are Heroes,” IEEE Software, March 1995, 97. 153.  Andreas Brennecke and Reinhard Keil-Slawik, “Position Papers for Dagstuhl Seminar 9635 on History of Software Engineering,” August 26–30, 1996, 35, 2. 154.  “Spectral Lines: Learning from Software Failure,” 8. 155.  Mahoney points out, “Almost from the start studies showed that the bulk of the errors occurred at the beginning of projects, before programming ever began (or should have begun).” Mahoney, “The Histories of Computing(s),” 128. 156.  Kuldeep Kumar and Niels Bjorn-Andersen, “A Cross-Cultural Comparison of IS Designer Values,” Communications of the ACM 33, no. 5 (1990): 528. 157.  Ibid.,535, 537. 158.  Nuseibeh and Easterbrook, “Requirements Engineering: A Roadmap,” 44. 159. Ibid. 160.  Robinson et al., “Postmodern Software Development,” 367. 161.  Ibid., 369, 366, 374. 162.  These include five hours on group dynamics and psychology, ten hours on communications skills, and two hours on project personnel and organization. IEEE Computer Society and Association for Computing Machinery Joint Task Force on Computing Curricula, Software Engineering 2004: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering (New York: IEEE-CS and ACM, 2004), 21. 163. CCSE Steering Committee, “Review Comments for CCSE Volume (First Draft-7/17/03),” 2003, 5. The curriculum effort was originally named “CCSE (Computing Curriculum Software Engineering)” and then renamed “SE2004.” Mandrioli was the only reviewer who commented on the inclusion of communications skills. 164.  For example, a recent report by the National Academy of Engineering found that young Americans see engineering as a largely masculine field and that few girls regard it as an appealing career path. National Academy of Engineering, Committee on Public Understanding of Engineering Messages, Changing the Conversation: Messages for Improving Public Understanding of Engineering, 58–59, 65, 89.

Chapter 4 1.  Stephanie Shirley, “Women in Data Processing,” Management Decision 19, no. 7 (1981): 32–33. 2.  “What was thought to be a glass ceiling problem has turned out to be, in large part, a problem that might more accurately be termed ‘the maternal wall.” Faye J. Crosby, Joan C. Williams, and Monica Biernat, “The Maternal Wall,” Journal of Social Issues 60, no. 4 (2004): 677. For gendered divisions of labor between public and domestic spheres, see Janet Saltzman Chafetz, “The Gender Division of Labor and the Reproduction of Female Disadvantage,” Journal of Family Issues

Notes  211

9, no. 1 (1988): 108–131, and Philip N. Cohen, “The Gender Division of Labor: ‘Keeping House’ and Occupational Segregation in the United States,” Gender and Society 18, no. 2 (2004): 239–252. For inadequacy of the concept of work-family balance, see Rhona Rapoport, Lotte Bailyn, Joyce K. Fletcher, and Bettye H. Pruitt, Beyond Work-Family Balance: Advancing Gender Equity and Workplace Performance (Hoboken, NJ: Wiley, 2002). 3.  Jeffrey R. Yost, “Programming Enterprise: Women Entrepreneurs in Software and Computer Services,” in Gender Codes: Why Women Are Leaving Computing, ed. Thomas Misa (Hoboken, NJ: Wiley, 2010), 229–250. 4.  Mary Lee Berners-Lee, interview by Janet Abbate, September 12, 2001. That first child was Tim Berners-Lee, who went on to invent the World Wide Web. 5.  Bobby Hersom, interview by Janet Abbate, September 20, 2001. 6.  Laurie Keller, Email to “witch” (women in computing history) discussion list, 1999. 7.  Lois Haibt, interview by Janet Abbate, August 2, 2001. 8.  Judy Clapp, interview by Janet Abbate, February 11, 2001, emphasis in original. 9.  This chapter focuses on industry rather than academic computer science, but women pursuing academic careers in later years reported having an easier time balancing work and family because of the more flexible hours. In addition, a group of women employed by the Los Alamos National Laboratory in the 1950s reported that the U.S. government offered them flexible hours and, if not actual help with childcare, at least the freedom to improvise their own solutions. Marge Devaney recalled that “in the early days there was at least one woman that used to bring her baby in. . . . She’d just bring it in and set it on the floor in a basket and take care of it when it needed care.” Marge Devaney, interview by Janet Abate, April 4, 2002. Devaney herself was able to work half-time at the lab while her daughter was young. Mary Menzel, who continued to work full-time on a flexible schedule after having two children, reported, “If my kid was sick and I didn’t get there, no one complained.” Mary Menzel, interview by Janet Abbate, April 4, 2002. Los Alamos may have been an unusual case, since the lab’s physical isolation in the New Mexico desert made it difficult to recruit technical workers and put a premium on retaining them. But this anecdotal evidence suggests that further research is needed on how women’s career options were shaped by the different work cultures of the government, industry, and academic sectors. 10.  Joan C. Williams and Holly Cohen Cooper, “The Public Policy of Motherhood,” Journal of Social Issues 60, no. 4 (2004): 849. See also Chafetz, “The Gender Division of Labor and the Reproduction of Female Disadvantage.” Ferree points out that the norm of the male provider is a myth because a substantial number of wives and daughters have always worked and the male as sole wage earner is a comparatively recent historical phenomenon. Myra Marx Ferree, “Beyond Separate Spheres: Feminism and Family Research,” Journal of Marriage and the Family 52 (1990): 871–872. But Shelley J. Correll, Stephen Benard, and In Paik note in a controlled study of salary decisions that the “marriage premium” or “family wage” for males still exists in practice, even though it is “formally extinct.”

212  Notes

Shelley J. Correll, Stephen Benard, and In Paik, “Getting a Job: Is There a Motherhood Penalty?,” American Journal of Sociology 112, no. 5 (2007): 1307, 1321. 11. Ferree, “Beyond Separate Spheres: Feminism and Family Research,” 874. Rapoport, Bailyn, Fletcher, and Pruitt note that “conditions in Western, capitalist, corporate work organizations . . . have, historically, been directed and shaped by white, married, middle-class men—people for whom paid work has been primary and whose characteristic strengths and skills have been enshrined in corporate cultures and reward systems.” Rapoport. Bailyn, Fletcher, and Pruitt, Beyond Work-Family Balance: Advancing Gender Equity and Workplace Performance, 2. 12.  Surveying recent sociological studies, Crosby, Williams, and Biernat conclude that “Part-time work is often seen as part committed and sometimes as part competent.” Crosby, Williams, and Biernat, “The Maternal Wall,” 677–678. Williams and Cooper note that “Rigid notions of the ideal worker reinforce much of the discrimination against part-time workers” and point out that U.S. laws exacerbate the problem by restricting many benefits and protections to full-time workers. Williams and Cooper, “The Public Policy of Motherhood,” 854. 13.  Amy J. C. Cuddy, Susan T. Fiske, and Peter Glick, “When Professionals Become Mothers, Warmth Doesn’t Cut the Ice,” Journal of Social Issues 60, no. 4 (2004): 701. 14.  Various studies have demonstrated how stereotypes about mothers affect employment decisions, resulting in significant penalties in hiring, pay, and promotion for women identified as mothers—even when their qualifications are identical to those of men or childless women. As Cecilia L. Ridgeway and Shelley J. Correll point out, “From a logical point of view, it is difficult to see why taking on the role of primary caretaker should affect a person’s underlying ability, even if it does impact time commitments.” Cecilia L. Ridgeway and Shelley J. Correll, “Motherhood as a Status Characteristic,” Journal of Social Issues 60, no. 4 (2004): 691. For other controlled studies, see Kathleen Fuegen, Monica Biernat, Elizabeth Haines, and Kay Deaux, “Mothers and Fathers in the Workplace: How Gender and Parental Status Influence Judgments of Job-Related Competence,” Journal of Social Issues 60, no. 4 (2004): 737–754; Cuddy, Fiske, and Glick, “When Professionals Become Mothers, Warmth Doesn’t Cut the Ice”; Correll, Benard, and Paik, “Getting a Job: Is There a Motherhood Penalty?” 15.  Stephanie Shirley, interview by Janet Abbate, April 20, 2001. Unless otherwise noted, all further quotations from Stephanie Shirley come from this interview. 16.  Atsushi Akera, “Voluntarism and the Fruits of Collaboration: The IBM User Group, Share,” Technology and Culture 42, no. 4 (2001): 710–736; Luanne Johnson, “A View from the Sixties: How the Software Industry Began,” in From 0 to 1: An Authoritative History of Modern Computing, ed. Atsushi Akera and Rik Nebeker (New York: Oxford University Press, 2002), 101–109. 17.  See Martin Campbell-Kelly, From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry (Cambridge: MIT Press, 2003), 90, for numbers of computers. 18.  John Hendry, Innovating for Failure: Government Policy and the Early British Computer Industry (Cambridge: MIT Press, 1990), 196.

Notes  213

19.  The married couple who started software services firm Gentry, Inc. in California in 1974 said that at the time they did not know of any other services companies that hired independent contractors rather than employing their own staff. Grace Gentry, “Interview by Jeffrey R. Yost,” August 11, 2008, Charles Babbage Institute, University of Minnesota, Minneapolis, 2008, 31. Unlike FI and Comp Inc., Gentry, Inc. seems to have expected their contractors to work full time, judging from Grace Gentry’s comments: “You just assume any programmer is going to work two thousand hours a year” (27). 20. Campbell-Kelly, From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry, 3–4. 21. For estimates of programmers, see Martin Campbell-Kelly, “The Development and Structure of the International Software Industry, 1950–1990,” Business and Economic History 24, no. 2 (1995): 82, and Jeffrey R. Yost, “Maximization and Marginalization: A Brief Examination of the History and Historiography of the U.S. Computer Services Industry,” Entreprises et Histoire 40 (2005): 92. Herbert D. Benington, who headed the programming effort at Systems Development Corporation (SDC), recalled that “women turned out to be very good for the administrative programs. . . . One of our strongest groups had 80 percent women in it.” Henry S. Tropp, “A Perspective on SAGE: Discussion,” Annals of the History of Computing 5, no. 4 (1983): 386. Judy Clapp, quoted earlier, was on the original team for the SAGE prototype. 22.  Campbell-Kelly, “The Development and Structure of the International Software Industry, 1950–1990,” 82–83. 23. Campbell-Kelly, From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry, 50. See also Johnson, “A View from the Sixties: How the Software Industry Began”; Yost, “Maximization and Marginalization: A Brief Examination of the History and Historiography of the U.S. Computer Services Industry.” 24.  Yost, “Maximization and Marginalization: A Brief Examination of the History and Historiography of the U.S. Computer Services Industry,” 92–93; Campbell-Kelly, From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry, 86. 25.  Yost, “Maximization and Marginalization: A Brief Examination of the History and Historiography of the U.S. Computer Services Industry,” 96, citing a study by the Association of Data Processing Service Organizations (ADAPSO). 26. Campbell-Kelly, From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry, 75–78. 27.  I have found no record of any earlier female-headed startups, although many early software firms left no records, as discussed in ibid., 58, and Yost, “Programming Enterprise: Women Entrepreneurs in Software and Computer Services,” 230. According to Shirley, after she started her own business in 1962, “I went out of my way to try and meet the few business women in the sector, and I only found one, who was Dina [Vaughan].” 28.  John M. Ryan, It Can Be Done! (Newbury, UK: Scope Books, 1979), 121–126.

214  Notes

29. Campbell-Kelly, From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry, 50. 30. Ryan, It Can Be Done!, 126. 31. Campbell-Kelly, From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry, 5. 32.  Yost, “Maximization and Marginalization: A Brief Examination of the History and Historiography of the U.S. Computer Services Industry,” 92–93. 33.  Elsie Shutt, interview by Janet Abbate, February 9, 2001. Unless otherwise noted, all further quotations from Elsie Shutt come from this interview. 34. Cheryl Arena Muise, “Spotlight on Computations, Inc.,” Greater Boston Chapter Association for Women in Computing Newsletter, October 1980, 1. 35.  Tom Lloyd, “Steve Shirley and F International,” in Dinosaur & Co.: Studies in Corporate Evolution (London: Routledge & Kegan Paul, 1984), 62–64. 36.  Susan Bond, who took a computer science job at the Royal Radar Establishment in 1965, agreed that there was male bias in the UK civil service, because you were more likely to be promoted to the next grade if the panel thought you had the potential for further promotion to a senior position. “The ‘potential’ system was discriminatory. When I was put up for promotion to [Principal Scientific Officer] and wasn’t promoted, it was all to do with the assessment of my potential; I was told that somebody had said, in my line of management, ‘No, ridiculous; a woman could never reach that grade!’” As it turned out, Bond was promoted to the highest grade, becoming the first female Senior Principal Scientific Officer at the RRE. Susan Bond, interview by Janet Abbate, September 26, 2001. 37.  Ibid., 65–66. Shirley noted in our interview, “We called it ‘Freelance Programmers,’ so I must have had—well, I did have some idea of making it grow” (emphasis in original). Stephanie Shirley, interview by Janet Abbate, April 20, 2001. 38.  Ibid., 67–68. 39.  The company was renamed FI Group in 1988, renamed Xansa in 2001, and acquired by the French corporation Steria Group in 2007. 40.  “Obituary: Dame Hilary Cropper,” Times of London, January 14, 2005. 41.  Blythe Grossberg, “Elsie Shutt: Pioneer Businesswoman,” Harvard Post, July 20, 1990. 42.  Four of my British interviewees spontaneously mentioned FI. Mary Lee Berners-Lee regretted that FI had not been around when she was looking for part-time work, and three others briefly worked for FI—Bobby Hersom, Mary Coombs, and Judith Mills. 43.  Harold Bergstein, “The CEIR View,” Datamation (May 1963): 59. 44.  John F. Keane, “Interview by Martin Campbell-Kelly,” May 3, 2002, Charles Babbage Institute, University of Minnesota, Minneapolis, 8. The experience led Keane to develop and publish a book called Productivity Management. 45.  Harold Bergstein, “Computerized Reflections at CSC,” Datamation (March 1963): 42.

Notes  215

46.  See Gerald M. Weinberg, The Psychology of Computer Programming (New York: Van Nostrand Reinhold, 1971), discussed in chapter 3. 47.  Lloyd, “Steve Shirley and F International,” 65. 48.  Ibid., 67. According to Lloyd, the consultant from Urwick-Diebold was so impressed with Shirley’s business that “he wrote her out a personal cheque for £500 to tide the company over its first cash flow crisis” (67). For contemporary warnings about software firms growing faster than their financial management capabilities, see Harold Bergstein, “It’s Elmer’s Turn,” Datamation (April 1963): 49–50; Bergstein, “The CEIR View,” 58. 49.  Bergstein, “The CEIR View,” 58. 50.  Shirley also soon developed a strategy to minimize the risk that a fixed-price job would balloon out of control and put the company in the red: she took on a large fixed-price contract only if it represented less than 25 percent of her total workload (or 20 percent as the company got larger). Lloyd, “Steve Shirley and F International,” 68. 51.  Ibid., 69. 52.  “Mixing Math and Motherhood,” Business Week, March 2, 1963, 87. 53. Peter C. Grindley, The UK Software Industry (London: London Business School, 1988), 77. 54. Campbell-Kelly, From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry, 82–86. 55.  Ibid., 86. 56.  Lloyd, “Steve Shirley and F International,” 71. 57.  FI acquired Heights in 1983, giving FI a U.S. foothold. Ibid., 74–75. 58.  Muise, “Spotlight on Computations, Inc.” 59. Yost, “Programming Enterprise: Women Entrepreneurs in Software and Computer Services,” 238–239. 60.  Lloyd, “Steve Shirley and F International,” 72–73. 61.  Grossberg, “Elsie Shutt: Pioneer Businesswoman.” Grossberg quotes Shutt as complaining that the photo implied that her workers were “taking care of a baby with one hand and writing programs with the other.” 62. “Mixing Math and Motherhood.” Ironically, feminist author Betty Friedan read the Business Week article and later used Shutt’s business as an example of a successful feminist career, as noted below. Betty Friedan, It Changed My Life: Writings on the Women’s Movement (New York: Random House, 1976), 46. 63.  Maureen Epstein, “Computer Women,” Guardian, January 31, 1964. Shirley reportedly found the Guardian article “of particular significance because of the publicity it gave to the idea behind her company.” Lloyd, “Steve Shirley and F International,” 66. 64.  Lloyd, “Steve Shirley and F International,” 68. 65. Campbell-Kelly, From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry, 66, quoting a 1964 CSC ad in Datamation.

216  Notes

66. Valerie Rockmael, “The Woman Programmer: A Subjective Reflection,” Datamation (January 1963): 41. 67.  Reprinted in Friedan, It Changed My Life: Writings on the Women’s Movement, 46. 68.  Teresa Poole, “The IT Woman,” The Independent, January 5, 2000. 69. Campbell-Kelly, From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry, table 1.4, p. 21. The other 22 percent was for integrated systems. 70. The U.S. 2002 Economic Census, category 541511 (custom computer programming services), gives a figure of 48,920 establishments. However, this counts only firms with employees. For the general category of software services (5415), there were 3.6 times as many firms with no employees. Applying this multiplier to the subcategory of programming, the total number of firms would be roughly 177,000. U.S. Department of Commerce, Bureau of the Census, U.S. Census, “Nonemployer Statistics,” 2002 Economic Census (Washington, DC: U.S. Government Printing Office, 2002). This is probably a conservative figure, since statistics from the 2002 SBO Company Summary show that the ratio of nonemployers to employers was closer to 4:1. Note that the failure to include small businesses without employees in the widely used Economic Census figures undercounts women’s entrepreneurial activity and may contribute to women’s invisibility in popular perceptions of computing. The U.S. Census 2002 Report: Women and Minorities counted 68,506 women-owned businesses in category 5415 (computer systems design and related services). To estimate the number of women doing “custom computer programming services” (subcategory 541511), I first calculated the percentage that this subcategory constituted of the more general 5415 category, using figures from the 2002 Economic Census. U.S. Census, Computer Systems Design and Related Services: 2002. I then applied this figure (46 percent) to the statistics on women business owners. This is a rough estimate, since the Economic Census counts only larger businesses (those with employees). I had to assume that the 46 percent ratio would apply to smaller businesses as well. However, the 18 percent figure for women for the 5415 category is supported by figures from the U.S. Census 2002 SBO survey, which found that of the 376,853 businesses in this sector, 72 percent were male-owned, 18 percent female-owned, and the rest equally owned or unknown gender. SBO Company Summary, 2002, p. 9. 71.  In some ways, men are even more trapped by the image of the “ideal” childfree worker; employers’ ongoing resistance to men taking family time is evidence that the bias against parents goes beyond women. See Suzanne Braun Levine, Father Courage: What Happens When Men Put Family First (Orlando, FL: Harcourt, 2000), and Rapoport et al., Beyond Work-Family Balance: Advancing Gender Equity and Workplace Performance. 72.  Correll, Benard, and Paik, “Getting a Job: Is There a Motherhood Penalty?,” 1298, 1306. Specifically, “The competence ratings are approximately 10% lower for mothers than for nonmothers, and the commitment ratings are about 15% lower. .  .  . The recommended starting salary for mothers was $11,000 (7.4%)

Notes  217

less than that offered to nonmothers, a significant difference. Mothers were also rated as significantly less promotable and were less likely to be recommended for management” (1316). Fathers, in contrast, were given higher ratings and salaries than childless men. In both laboratory studies and audit tests of real employers, childless women were recommended for hire about twice as often as mothers with identical qualifications (1299, 1330). The study’s fictitious job applicants were professional but not technical (marketing managers); a question for further study is whether technical workers would pay a greater or lesser penalty for being mothers. See note 14 for other related studies. 73.  Williams and Cooper, “The Public Policy of Motherhood,” 850. 74.  Erika Szyszczak, “Differences in Pay for Part-Time Work,” Modern Law Review 44, no. 6 (1981): 673. 75.  Ridgeway and Correll, “Motherhood as a Status Characteristic,” 691. 76.  Jack Nilles, “MIS and Telecommuting: Friends or Foes?,” Uniforum’s IT Solutions (February 1996), 32. 77. Cuddy, Fiske, and Glick, “When Professionals Become Mothers, Warmth Doesn’t Cut the Ice,” 714. 78.  Council of the European Union, “Council Directive 97/81/EC of 15 December 1997 Concerning the Framework Agreement on Part-Time Work,” OJ L (Official Journal of the European Union, Legislation) 14 (1998): 13. 79.  A. Panteli, J. Stack, M. Atkinson, and H. Ramsay, “The Status of Women in the UK IT Industry: An Empirical Study,” European Journal of Information Systems 8 (1999): 177–178, 180.

Chapter 5 1.  J. McGrath Cohoon and William Aspray, “A Critical Review of the Research on Women’s Participation in Postsecondary Computing Education,” in Women and Information Technology: Research on Underrepresentation, ed. J. McGrath Cohoon and William Aspray (Cambridge: MIT Press, 2006), 174. 2.  U.S. Department of Education, National Center for Education Statistics, Chartbook of Degrees Conferred, 1969–70 to 1993–94, ed. Project Officer Thomas D. Snyder (Washington, DC: U.S. Government Printing Office, 1997), table 5. 3.  National Science Foundation, Division of Science Resources Statistics, “Women, Minorities, and Persons with Disabilities in Science and Engineering: 2011,” Special Report NSF 11-309, Arlington, VA, tables 5-2, 6-2, 7-2. http://www.nsf .gov/statistics/wmpd. 4.  Higher Education Statistics Agency, “HESA Statistical First Release 153: Higher Education Student Enrolments and Qualifications Obtained at Higher Education Institutions in the United Kingdom for the Academic Year 2009/10,” Cheltenham, UK, 2011, table 7. 5.  Caroline Clarke Hayes, “Computer Science: The Incredible Shrinking Woman,” in Gender Codes: Why Women Are Leaving Computing, ed. Thomas Misa (Hoboken, NJ: Wiley, 2010), 32.

218  Notes

6. Computing Research Association, 2009, “Taulbee Survey,” 15 (http://www .cra.org/resources/taulbee); Higher Education Statistics Agency, “Resources of Higher Education Institutions 2003/04,” Cheltenham, UK, 2005, table 12a. The UK statistical categories designate “cost centres” at universities for accounting purposes and do not necessarily correspond accurately to disciplinary boundaries. An earlier study by Frances Grundy focused more narrowly on “computer studies” and found that the percentage of female staff was only 14 percent in 1991. Rachel Lander and Alison Adam, eds., Women in Computing (Exeter, UK: Intellect Books, 1997), 5. In 1994, women were 16 percent of full-time staff in the sciences (including computing), while in engineering and technology they were only 9 percent. Judith Rich, “Gender Segregation in the Academic Staff of Universities in Great Britain, 1980/81–1993/94,” Economica 66 (1999): 512, table 2). 7.  Donna J. Nelson, “A National Analysis of Diversity in Science and Engineering Faculties at Research Universities,” Norman, OK, 2007, 2, table 1, and 3, table 2. 8.  Cohoon and Aspray, “A Critical Review of the Research on Women’s Participation in Postsecondary Computing Education,” 164, 171. 9.  Hayes, “Computer Science: The Incredible Shrinking Woman,” 26, 44. 10.  Cohoon and Aspray, “A Critical Review of the Research on Women’s Participation in Postsecondary Computing Education,” 157; Wendy M. Williams and Stephen J. Ceci, “When Scientists Choose Motherhood,” American Scientist 100, no. 2 (2012): 138–140. 11.  Janet Abbate, “The Pleasure Paradox: Bridging the Gap between Popular Images of Computing and Women’s Historical Experiences,” in Gender Codes: Why Women Are Leaving Computing, ed. Thomas Misa (Hoboken, NJ: Wiley, 2010), 213–227. 12. Louis Fein, “Letter to the Editor,” Communications of the ACM 2, no. 9 (1959): 8. 13.  See, e.g., Allen Newell, Alan Perlis, and Herbert A. Simon, “Computer Science (Letter to the Editor),” Science 157, no. 3795 (1967): 1373–1374; Paul Ceruzzi, “Electronics Technology and Computer Science, 1940–1975: A Coevolution,” Annals of the History of Computing 10, no. 4 (1989): 267–268; Mario L. Juncosa, “Will You Vote for an Association Name Change to ACIS?,” Communications of the ACM 8, no. 7 (1965): 424; Michael S. Mahoney, “Finding a History for Software Engineering,” IEEE Annals of the History of Computing 26, no. 1 (2004): 10. 14.  William Aspray, “Was Early Entry a Competitive Advantage? U.S. Universities That Entered Computing in the 1940s,” Annals of the History of Computing 22, no. 3 (2000): 42–87. Aspray reports that “by 1954 nineteen M.S. degrees and eight Ph.D.s had been awarded in the program” (52). 15.  William Aspray and Bernard O. Williams, “Arming American Scientists: NSF and the Provision of Scientific Computing Facilities for Universities, 1950–1973,” Annals of the History of Computing 16, no. 4 (1994): 60–74; Paul E. Ceruzzi, A History of Modern Computing (Cambridge: MIT Press, 1998), 44; P. A. Samet, “The Evolution of Computer Science Teaching and Research in the UK,” Paper presented at the Conference on Computers in Europe: Past, Present and Future, Kiev, 1998; Martyn Clark, “State Support for the Expansion of UK University

Notes  219

Computing in the 1950s,” IEEE Annals of the History of Computing 32, no. 1 (2010): 23–33. 16.  Samet, “The Evolution of Computer Science Teaching and Research in the UK,” 6. 17.  ACM Curriculum Committee on Computer Science, “An Undergraduate Program in Computer Science: Preliminary Recommendations,” Communications of the ACM 8 (1965): 544. 18.  Robert W. Rector, “Statement of Principles,” Communications of the ACM 9, no. 4 (1966): 247. 19.  National Science Foundation, Science and Engineering Degrees: 1966–2001, Special Report NSF 11-309, ed. Susan T. Hill and Jean M. Johnson (Arlington, VA: NSF, 2004), table 46. 20.  Material for this section comes from Sara Kiesler, Lee Sproull, and J. S. Eccles, “Pool Halls, Chips, and War Games: Women in the Culture of Computing,” Psychology of Women Quarterly 9, no. 2 (1985): 451–462; Ellen Spertus, “Why Are There So Few Female Computer Scientists?,” MIT Artificial Intelligence Laboratory, 1991; Gillian Lovegrove and Barbara Segal, eds., Women into Computing: Selected Papers, 1988–1990 (London: Springer-Verlag,1991); Maria Klawe and Nancy Leveson, “Women in Computing: Where Are We Now?,” Communications of the ACM 38, no. 1 (1995): 29–35; Tracy Camp, “The Incredible Shrinking Pipeline,” Communications of the ACM 40, no. 10 (1997): 103–110; Lander and Adam, Women in Computing; Denise Gürer and Tracy Camp, “An ACM-W Literature Review on Women in Computing,” Inroads: SIGCSE Bulletin 34, no. 2 (2002): 121–127; and the edited volumes J. McGrath Cohoon and William Aspray, eds., Women and Information Technology: Research on Underrepresentation (Cambridge: MIT Press, 2006), Thomas Misa, ed., Gender Codes: Why Women Are Leaving Computing (Hoboken, NJ: Wiley, 2010), and Williams and Ceci, “When Scientists Choose Motherhood,” 138–140. 21. See, e.g., Gürer and Camp, “An ACM-W Literature Review on Women in Computing,” 122; Randall Stross, “What Has Driven Women out of Computer Science?, ” New York Times, November 16, 2008. Even though women now make up 40 percent of gamers, games remain heavily gender stereotyped and gaming culture is often hostile to women. Entertainment Software Association, 2008 Essential Facts About the Computer and Video Game Industry (Washington, DC: ESA, 2008). 22.  Jane Margolis and Allan Fisher, Unlocking the Clubhouse: Women in Computing (Cambridge: MIT Press, 2002). 23.  Spertus, “Why Are There So Few Female Computer Scientists?,” 17; Cohoon and Aspray, “A Critical Review of the Research on Women’s Participation in Postsecondary Computing Education,” 161. 24.  Nelson, “A National Analysis of Diversity in Science and Engineering Faculties at Research Universities,” 4. 25.  Klawe and Leveson, “Women in Computing: Where Are We Now?,” 32. 26.  Quoted in Nelson, “A National Analysis of Diversity in Science and Engineering Faculties at Research Universities,” 5.

220  Notes

27.  Sociologist of science Robert K. Merton dubbed this the “Matthew effect,” after Bible verse Matthew 25:29: “For to all those who have, more will be given.” Robert K. Merton, “The Matthew Effect in Science,” Science 159, no. 3810 (1968): 56–63. Margaret Rossiter expanded this concept to include gender, coining the phrase “Matilda effect” to describe the tendency for female scientists’ accomplishments to be ignored or attributed to men. Margaret W. Rossiter, “The Matilda Effect in Science,” Social Studies of Science 23 (1993): 325–341. 28.  Klawe and Leveson, “Women in Computing: Where Are We Now?,” 34. 29.  Hayes, “Computer Science: The Incredible Shrinking Woman,” 29. 30.  Laurie Keller, interview by Janet Abbate, September 26, 2001. 31.  For the history and politics of the pipeline metaphor in the United States, see Juan Lucena, Defending the Nation: U.S. Policymaking to Create Scientists and Engineers from Sputnik to the ‘War against Terrorism’ (Lanham, MD: University Press of America, 2005). 32.  See Margaret Rossiter, Women Scientists in America: Strategies and Struggles to 1940 (Baltimore: Johns Hopkins, 1982); Margaret Rositer, Women Scientists in America: Before Affirmative Action, 1940–1972 (Baltimore: Johns Hopkins, 1995). In calling jobs at lower-status institutions “dead ends,” I do not mean to imply that those faculty do not enjoy or excel at their work but rather that they receive a much smaller share of the rewards, recognition, and resources than faculty at more prestigious institutions. 33.  Five of my interviewees obtained academic positions in the United Kingdom with only a bachelor’s degree—Jean Bacon, Pam Morton, Chris Warner, Sylvia Wilbur, and one American, Laurie Keller. Five others obtained academic positions with a master’s degree—Gillian Lovegrove, Hilary Kahn, Jean Dollimore, and Karen Shipp in the United Kingdom and Joyce Currie Little in the United States. Most had prior work experience in programming or systems design. 34.  Recent figures from the UK Higher Education Statistics Agency show that women make up a higher percentage of the faculty—and earn more—at these “new universities” (former polytechnics) than at traditional institutions. Rebecca Attwood, “Pay Bias Persists as Change Is ‘Too Slow,’” Times Higher Education Supplement, May 11 2007. 35.  Gillian Lovegrove, interview by Janet Abbate, September 20, 2001. 36.  Jean Bacon, interview by Janet Abbate, April 10, 2001. 37.  Karen Sparck-Jones had been doing research in the Cambridge computer lab since 1968 but did not obtain an official academic position (as assistant director of research) until 1988. 38.  Hilary Kahn, interview by Janet Abbate, April 18, 2001. 39.  Susan Graham, interview by Janet Abbate, July 10, 2002. 40.  ACM history page, http://www.acm.org/about/history, accessed October 22, 2010. 41.  Harry Earl Goheen, “Interview by Henry S. Tropp,” August 15, 1972, Computer Oral History Collection, Smithsonian Institution National Museum of

Notes  221

American History. See also Kurt W. Beyer, Grace Hopper and the Invention of the Information Age (Cambridge: MIT Press, 2009), 167. 42.  Hagley Archives, Sperry Rand Corporation, Engineering Research Associates Division: Records, 1949–1965, record #2015, series I, box 2, folder 30 (ACM records), “Members as of May 21, 1948.” 43. IEEE Computer Society history page, http://www.computer.org/portal/web/ about/history, accessed October 15, 2010. 44.  Barbara Liskov, interview by Janet Abbate, February 8, 2001. 45.  Anita Borg, interview by Janet Abbate, January 5, 2001. 46.  Roy Levin and Dave Redell, “Foreword,” in Proceedings of the Ninth ACM Symposium on Operating Systems Principles (New York: ACM, 1983), v. 47.  Anita Borg, Jim Baumbach, and Sam Glazer, “A Message System Supporting Fault Tolerance,” in Proceedings of the Ninth ACM Symposium on Operating Systems Principles (New York: ACM, 1983), 90–99. Borg included the two other operating system developers on her project as coauthors, although she wrote the paper herself. The paper was cited forty-six times, ranking fifth out of sixteen among the conference papers. 48.  Adele Goldberg, interview by Janet Abbate, July 3, 2002. 49.  Susan Bond, interview by Janet Abbate, September 26, 2001. 50.  Fan Chung Graham, interview by Janet Abbate, July 18, 2002. 51.  Samet, “The Evolution of Computer Science Teaching and Research in the UK,” 7. 52.  Jean Sammet, interview by Janet Abbate, August 29, 2001. 53.  Fran Allen, interview by Janet Abbate, August 2, 2001. 54.  ACM Web site, http://www.acm.org/about/past-presidents. 55.  IEEE Computer SocietyWeb site,http://www.computer.org/portal/web/cshistory/ officers, accessed May 11, 2011. 56. “BCS Past Presidents,” http://www.bcs.org/content/conWebDoc/1635, accessed May 11, 2011. Of the BCS presidents, all but Wendy Hall were on the business rather than academic side of computing. 57.  “National ACM Membership Survey,” Communications of the ACM 20, no. 10 (1977): 689–692; Wendy Hall et al., “ACM Membership Gender Study,” Paper presented at the Grace Hopper Celebration of Women in Computing, October 3, 2008, Keystone, Colorado. 58.  Chris Warner, interview by Janet Abbate, April 24, 2001. 59.  Anita Borg, interview by Janet Abbate, January 5, 2001. 60. Ibid. 61.  http://anitaborg.org/protected/faq, accessed May 30, 2011. 62. http://anitaborg.org/initiatives/systers/systers-techtalk-email-list. 63.  Anita Borg, interview by Janet Abbate, January 5, 2001. 64.  David A. Patterson, “The Health of Research Conferences and the Dearth of Big Idea Papers,” Communications of the ACM 47, no. 12 (2004): 23.

222  Notes

65.  Anita Borg, interview by Janet Abbate, January 5, 2001. 66. Anita Borg, “Women Defining Technology for the Twenty-first Century: A Report from America,” in Women, Work and Computerization: Breaking Old Boundaries, Building New Forms, ed. Alison Adam, Judy Emms, Eileen Green, and Jenny Owen (Amsterdam: Elsevier, 1994), 232. 67.  The series of GHC conferences includes Washington, DC, 1994; San Jose, CA, 1997; Hyannis, Massachusetts, 2000; Vancouver, British Columbia, 2002; Chicago, Illinois, 2004; San Diego, California, 2006; Orlando, Florida, 2007; Keystone, Colorado, 2008; Tucson, Arizona, 2009; Atlanta, Georgia, 2010; Portland, Oregon, 2011. Each conference since 2000 has had a theme. 68.  http://www.dcs.qmul.ac.uk/women/LondonHopper.php,http://anitaborg.org/ initiatives/grace-hopper-regional-consortium, and http://anitaborg.org/initiatives/ grace-hopper-celebration-india, all accessed June 1, 2011. 69.  Telle Whitney, interview by Janet Abbate, July 16, 2002. 70. Hall et al., “ACM Membership Gender Study,” 9; http://www.oopsla.org/ oopsla2008/program-overview/panels.html; SOSP 2007 program, http://www .sosp2007.org/program.html. 71.  Carol Frieze et al., “Culture and Environment as Determinants of Women’s Participation in Computing: Revealing the ‘Women-CS Fit’,” in SIGCSE ‘06 (New York: ACM, 2006). 72.  A promotional video shot at the 2008 GHC conference called “I am a Technical Woman” suggests the importance of intervening in the public image of computing. The video’s dialog consists entirely of the phrase “I am a technical woman” repeated over and over by conference-goers of various ages, ethnicities, and professional positions, implying that simply to have so many women publicly claim the identity “technical woman” is boldly empowering. Without that understanding of identity politics, the video would make no sense. 73. “See Jane Compute” blog, http://scienceblogs.com/seejanecompute/2008/08/ i_just_did_something_i_thought.php, accessed June 1, 2011, emphasis in original. 74.  Fran Berman, interview by Janet Abbate, July 18, 2002. 75.  Fran Berman, interview by Janet Abbate, July 18, 2002. 76.  Anita Borg, interview by Janet Abbate, January 5, 2001. 77.  Patty L., “Why Patty’s Glad She Went to GHC,” GHC blog, September 2, 2009. 78.  Anita Borg, interview by Janet Abbate, January 5, 2001. 79. Ibid. 80.  See, e.g., Margolis and Fisher, Unlocking the Clubhouse: Women in Computing. Frieze and her colleagues argue that these differences in men’s and women’s interest in technology versus social utility disappeared when their computer science department became more gender balanced and more diverse in terms of student background and personality. Frieze et al., “Culture and Environment as Determinants of Women’s Participation in Computing: Revealing the ‘Women-CS Fit’.” This finding does not mean that the “tool versus toy” distinction does not

Notes  223

have gender connotations but rather suggests that students in the gender-balanced environment felt more comfortable expressing interests that were not associated with their gender. A 2007 survey of ACM members showed that women were more interested in applications and social contexts (milieux) of computing than men were. Hall et al., “ACM Membership Gender Study,” slide 14. 81. Caroline Simard and Elizabeth Bandy, “Grace Hopper Conference 2008 Evaluation and Impact Report,” Anita Borg Institute for Women and Technology, 2009, 44. 82.  Ibid., 11. 83. GHC is not included in DBLP, a bibliographic authority in computer science (http://www.informatik.uni-trier.de/~ley/db/about/faqdblp.html) or in various Web sites that rank computer science conferences (http://www.cs.albany .edu/~ashwin/Conf_rank.html; http://cs.conference-ranking.net; http://webdocs .cs.ualberta.ca/~zaiane/htmldocs/ConfRanking.html). 84.  Patterson, “The Health of Research Conferences and the Dearth of Big Idea Papers,” 23. 85.  Deanna Kosaraju, email to Janet Abbate, September 16, 2010. 86.  Borg, “Women Defining Technology for the Twenty-first Century: A Report from America,” 237–238.

 

Bibliography

Abbate, Janet. “The Pleasure Paradox: Bridging the Gap between Popular Images of Computing and Women’s Historical Experiences.” In Gender Codes: Why Women Are Leaving Computing, edited by Thomas Misa, 213–227. Hoboken, NJ: Wiley, 2010. Abbate, Janet, ed. Special issue on Women and Gender in the History of Computing. Annals of the History of Computing 25, no. 4 (2003). ACM Curriculum Committee on Computer Science. “An Undergraduate Program in Computer Science: Preliminary Recommendations.” Communications of the ACM 8 (1965): 543–552. Adams, Jeanne C. “Discussion of Jacobs Paper.” In Proceedings of the Eleventh SIGCPR Conference on Computer Personnel Research, 111–114. New York: ACM, 1973. Aiken, Howard. “Interview by Henry Tropp and I. B. Cohen.” February 26–27, 1973. Computer Oral History Collection, Smithsonian Institution National Museum of American History. Akera, Atsushi. “Voluntarism and the Fruits of Collaboration: The IBM User Group, Share.” Technology and Culture 42, no. 4 (2001): 710–736. Allan, J. C. C. “The Selection and Training of Computer Personnel in the United Kingdom.” In Proceedings of the Sixth SIGCPR Conference on Computer Personnel Research, 64–80. New York: ACM, 1968. Allen, Fran, Paula Hawthorn, and Barbara Simons. “Not Now, Not Like This: Why the ACM Council Does Not Support the Licensing of Software Engineers at This Time.” Communications of the ACM 43, no. 2 (2000): 29–30. Alvey Committee. A Programme for Advanced Information Technology: The Report of the Alvey Committee. London: UK Department of Industry, 1982. Armer, Paul. “Problems in Administrative Leadership in the Computer Field.” In Proceedings of the Second SIGCPR Conference on Computer Personnel Research, 93–101. New York: ACM, 1964.

226  Bibliography

Aspray, William. “Command and Control, Documentation, and Library Science: The Origins of Information Science at the University of Pittsburgh.” Annals of the History of Computing 21, no. 4 (1999): 4–20. Aspray, William. John Von Neumann and the Origins of Modern Computing. Cambridge: MIT Press, 1990. Aspray, William. “The Stored Program Concept.” IEEE Spectrum 27 (1990): 51. Aspray, William. “Was Early Entry a Competitive Advantage? U.S. Universities That Entered Computing in the 1940s.” Annals of the History of Computing 22, no. 3 (2000): 42–87. Aspray, William, and Bernard O. Williams. “Arming American Scientists: NSF and the Provision of Scientific Computing Facilities for Universities, 1950–1973.” Annals of the History of Computing 16, no. 4 (1994): 60–74. Attwood, Rebecca. “Pay Bias Persists as Change Is ‘Too Slow.’” Times Higher Education Supplement, May 11, 2007, 1. Bach, James. “Enough about Process: What We Need Are Heroes.” IEEE Software (March 1995): 96–98. Backus, J. W. “The History of FORTRAN I, II, and III.” IEEE Annals of the History of Computing 1, no. 1 (1979): 21–37. Backus, J. W. “The IBM 701 Speedcoding System.” Journal of the ACM 1, no. 1 (1953): 4–5. Backus, J. W., R. J. Beeber, S. Best, R. Goldberg, L. M. Haibt, H. L. Herrick, R. A. Nelson, et al. “The FORTRAN Automatic Coding System.” Paper presented at the IRE-AIEE-ACM Western Joint Computer Conference, 1957. Backus, John. “Programming in America in the 1950s: Some Personal Impressions.” In A History of Computing in the Twentieth Century, edited by Nicholas Metropolis, Jack Howlett, and Gian-Carlo Rota, 125–135. New York: Academic Press, 1980. Barley, Stephen R., and Gideon Kunda. Gurus, Hired Guns, and Warm Bodies: Itinerant Experts in a Knowledge Economy. Princeton, NJ: Princeton University Press, 2004. Barnes, Bruce H., and Malcolm H. Gotterer. “Attributes of Computer Professionals.” In Proceedings of the Ninth SIGCPR Conference on Computer Personnel Research, 167–179. New York: ACM, 1971. Barnes, Bruce. “Interview by William Aspray.” September 26, 1990. Charles Babbage Institute, University of Minnosota, Minneapolis. Bemer, R. W. “A View of the History of COBOL.” Honeywell Computer Journal 5, no. 3 (1971): 130–135. Berger, Raymond M. “Selection of Systems Analysts and Programmer Trainees.” In Proceedings of the Sixth SIGCPR Conference on Computer Personnel Research, 44–63. New York: ACM, 1968. Bergstein, Harold. “The CEIR View.” Datamation (May 1963): 55–59. Bergstein, Harold. “Computerized Reflections at CSC.” Datamation (March 1963): 39–42.

Bibliography  227

Bergstein, Harold. “It’s Elmer’s Turn.” Datamation (April 1963): 48–55. Bernstein, Arthur J. “A Programmmer Training Project.” Communications of the ACM 14, no. 7 (1971): 449–452. Beyer, Kurt W. Grace Hopper and the Invention of the Information Age. Cambridge: MIT Press, 2009. Biamonte, A. J. “Predicting Success in Programmer Training.” In Proceedings of the Second SIGCPR Conference on Computer Personnel Research, 9–12. New York: ACM, 1964. Bigart, Homer. “Experts Divided over Automation.” New York Times, December 28, 1955, 14. Boehm, Barry. “Software Engineering—as It Is.” In ICSE ’79: Proceedings of the Fourth International Conference on Software Engineering, 11–21. Piscataway, NJ: IEEE Press, 1979. Bolton, Paul. House of Commons Library Standard Note, Education: Historical Statistics. London: UK Parliament, House of Commons, 2007. Booth, P. M. A. “Training and Development Plans and Results at Mobil Data Services Ltd.” In Proceedings of the Ninth SIGCPR Conference on Computer Personnel Research, 101–129. New York: ACM, 1971. Borg, Anita. “Women Defining Technology for the Twenty-first Century: A Report from America.” In Women, Work and Computerization, edited by Alison Adam, Judy Emms, Eileen Green, and Jenny Owen, 231–238. Amsterdam: Elsevier, 1994. Borg, Anita, Jim Baumbach, and Sam Glazer. “A Message System Supporting Fault Tolerance.” Proceedings of the Ninth ACM Symposium on Operating Systems Principles, 90–99. New York: ACM, 1983. Brandon, Dick H. “The Economics of Computer Programming.” In On the Management of Computer Programming, edited by George F. Weinwurm, 3–16. Philadelphia: Auerbach, 1970. Braverman, Harry. Labor and Monopoly Capital. New York: Monthly Review Press, 1974. Brennecke, Andreas, and Reinhard Keil-Slawik. “Position Papers for Dagstuhl Seminar 9635 on History of Software Engineering.” August 26–30, 1996. Brooks, Frederick P. The Mythical Man-Month: Essays on Software Engineering. Reading, MA: Addison-Wesley, 1975. Brooks, Frederick P. “No Silver Bullet: Essence and Accidents of Software Engineering.” Computer 20, no. 4 (1987): 10–19. Bunch, Charlotte. Passionate Politics: Feminist Theory in Action. New York: St. Martin’s Press, 1987. Burger, Carol J., Elizabeth G. Creamer, and Peggy S. Meszaros, eds. Reconfiguring the Firewall: Recruiting Women to Information Technology across Cultures and Continents. Wellesley, MA: A. K. Peters, 2007. Business Automation. “Nation-Wide Weekly Salary Data for All EDP Jobs.” Business Automation (June 1969): 48–59.

228  Bibliography

Butler, Judith. Gender Trouble. New York: Routledge, 1990. Caminer, David, J.B.B. Aris, P.M.R. Hermon, and F. F. Land. User-Driven Innovation: The World’s First Business Computer. New York: McGraw-Hill, 1996. Camp, Tracy. “The Incredible Shrinking Pipeline.” Communications of the ACM 40, no. 10 (1997): 103–110. Campbell, Betty. “About This Issue.” Annals of the History of Computing 18, no. 3 (1996): 3. Campbell-Kelly, Martin. “The Development and Structure of the International Software Industry, 1950–1990.” Business and Economic History 24, no. 2 (1995): 73–110. Campbell-Kelly, Martin. From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry. Cambridge: MIT Press, 2003. Campbell-Kelly, Martin, and William Aspray. Computer: A History of the Information Machine. New York: Basic Books, 1996. CCSE Steering Committee. “Review Comments for CCSE Volume (First Draft 7/17/03).” 2003. http://sites.computer.org/ccse/FirstReviewComments7-17-03. pdf. Central Statistical Office (UK). Annual Abstract of Statistics. Vol. 97. London: Her Majesty’s Stationery Office, 1960. Ceruzzi, Paul. “Electronics Technology and Computer Science, 1940–1975: A Coevolution.” Annals of the History of Computing 10, no. 4 (1989): 257–275. Ceruzzi, Paul E. A History of Modern Computing. Cambridge: MIT Press, 1998. Chafetz, Janet Saltzman. “The Gender Division of Labor and the Reproduction of Female Disadvantage.” Journal of Family Issues 9, no. 1 (1988): 108–131. Clark, Martyn. “State Support for the Expansion of UK University Computing in the 1950s.” IEEE Annals of the History of Computing 32, no. 1 (2010): 23–33. Clewlow, Carl W. “Managing Computer Programming in the Federal Government.” In On the Management of Computer Programming, edited by George F. Weinwurm, 19–33. Philadelphia: Auerbach, 1970. Cockburn, Cynthia. Machinery of Dominance. Boston: Northeastern University Press, 1988. Cockburn, Cynthia. “The Material of Male Power.” In The Social Shaping of Technology, edited by Donald MacKenzie and Judy Wajcman, 125–146. Philadelphia: Open University Press, 1985. Cohen, Philip N. “The Gender Division of Labor: ‘Keeping House’ and Occupational Segregation in the United States.” Gender and Society 18, no. 2 (2004): 239–252. Cohoon, J. McGrath, and William Aspray. “A Critical Review of the Research on Women’s Participation in Postsecondary Computing Education.” In Women and Information Technology: Research on Underrepresentation, edited by J. McGrath Cohoon and William Aspray, 137–180. Cambridge: MIT Press, 2006.

Bibliography  229

Cohoon, J. McGrath, and William Aspray, eds. Women and Information Technology: Research on Underrepresentation. Cambridge: MIT Press, 2006. “Computers: The Career of the Future.” London Times, June 17, 1969, 22. Computing Research Association. “Taulbee Survey.” 2009. http://www.cra.org/ resources/taulbee. Copeland, B. Jack. “Colossus and the Rise of the Modern Computer.” In Colossus: The Secrets of Bletchley Park’s Code-Breaking Computers, edited by B. Jack Copeland, 101–115. Oxford: Oxford University Press, 2006. Copeland, B. Jack, Catherine Caughey, Dorothy Du Boisson, Eleanor Ireland, Ken Myers, and Norman Thurlow. “Mr. Newman’s Section.” In Colossus: The Secrets of Bletchley Park’s Code-Breaking Computers, edited by B. Jack Copeland, 157– 175. Oxford: Oxford University Press, 2006. Correll, Shelley J., Stephen Benard, and In Paik. “Getting a Job: Is There a Motherhood Penalty?” American Journal of Sociology 112, no. 5 (2007): 1297–1338. Council of the European Union. “Council Directive 97/81/EC of 15 December 1997 Concerning the Framework Agreement on Part-Time Work.” OJ L (Official Journal of the European Union, Legislation) 14 (1998): 9–14. Croarken, Mary. “Mary Edwards: Computing for a Living in Eighteenth-Century England.” Annals of the History of Computing 25, no. 4 (2003): 9–15. Crosby, Faye J., Joan C. Williams, and Monica Biernat. “The Maternal Wall.” Journal of Social Issues 60, no. 4 (2004): 675–682. Cuddy, Amy J. C., Susan T. Fiske, and Peter Glick. “When Professionals Become Mothers, Warmth Doesn’t Cut the Ice.” Journal of Social Issues 60, no. 4 (2004): 701–718. Cunningham, Joseph F., and M. H. Schwartz. “A Dialogue on Managers, Data Processing Managers, and Computer Programming Managers.” In On the Management of Computer Programming, edited by George F. Weinwurm, 217–233. Philadelphia: Auerbach, 1970. Cusumano, Michael A. “Factory Concepts and Practices in Software Development.” IEEE Annals of the History of Computing 13, no. 1 (1991): 3–32. Davies, Margery W. Woman’s Place Is at the Typewriter: Office Work and Office Workers, 1870–1930. Philadelphia: Temple University Press, 1982. Dickmann, Robert A. “A Programmer Appraisal Instrument.” In Proceedings of the Second SIGCPR Conference on Computer Personnel Research, 45–64. New York: ACM, 1964. Dickmann, R. A., and J. Lockwood. “Computer Personnel Research Group, 1966 Survey of Test Use in Computer Personnel Selection.” In Proceedings of the Fourth SIGCPR Conference on Computer Personnel Research, 15–25. New York: ACM, 1966. Dijkstra, Edsger W. “Go to Statement Considered Harmful.” Communications of the ACM 11 (1968): 147–148.

230  Bibliography

Dijkstra, Edsger W. “Notes on Structured Programming.” Unpublished manuscript, August 1969. Dover, Clare. “The Under-Employed Sex.” New Scientist, February 29, 1968, 18–20. Eckert, J. Presper, Jr. “Disclosure of Magnetic Calculating Machine.” In A History of Computing in the Twentieth Century, edited by Nicholas Metropolis, Jack Howlett, and Gian-Carlo Rota, 538. New York: Academic Press, 1980. Eckert, J. Presper, Jr. “The ENIAC.” In A History of Computing in the Twentieth Century, edited by Nicholas Metropolis, Jack Howlett, and Gian-Carlo Rota, 525–539. New York: Academic Press, 1980. England, Paula. “The Case for Comparable Worth.” Quarterly Review of Economics and Finance 39 (1999): 743–755. Ensmenger, Nathan. “From ‘Black Art’ to Industrial Discipline: The Software Crisis and the Management of Programmers.” Ph.D. diss., University of Pennsylvania, 2001. Ensmenger, Nathan. The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise. Cambridge: MIT Press, 2010. Ensmenger, Nathan. “Making Programming Masculine.” In Gender Codes: Why Women Are Leaving Computing, edited by Thomas Misa, 115–141. Hoboken, NJ: Wiley, 2010. Ensmenger, Nathan L. “Letting the ‘Computer Boys’ Take Over: Technology and the Politics of Organizational Transformation.” International Review of Social History 48, suppl. (2003): 153–180. Entertainment Software Association. 2008 Essential Facts About the Computer and Video Game Industry. Washington, DC: ESA, 2008. Epstein, Maureen. “Computer Women.” Guardian, January 31, 1964. Farris, George F., and Rene Cordero. “What Do We Know about Managing Scientists and Engineers: A Review of Recent Literature.” Center for Innovation Management Studies, North Carolina State University, 2002. Fein, Louis. “Letter to the Editor.” Communications of the ACM 2, no. 9 (1959): 2. Fensom, Harry. “How Colossus Was Built and Operated.” In Colossus: The Secrets of Bletchley Park’s Code-Breaking Computers, edited by B. Jack Copeland, 297–304. Oxford: Oxford University Press, 2006. Ferree, Myra Marx. “Beyond Separate Spheres: Feminism and Family Research.” Journal of Marriage and the Family 52 (1990): 866–884. Fischer, George. Your Career in Computers. New York: Meredith Press, 1968. Flowers, Thomas H. “D-Day at Bletchley Park.” In Colossus: The Secrets of Bletchley Park’s Code-Breaking Computers, edited by B. Jack Copeland, 78–83. Oxford: Oxford University Press, 2006. Frank, Werner. “The History of Myth #1.” Datamation (May 1983): 252–263. Freeman, Jo. “Comparable Worth, Part I: Background.” In These Times, August 22–September 4, 1984, 16.

Bibliography  231

Friedan, Betty. It Changed My Life: Writings on the Women’s Movement. New York: Random House, 1976. Frieze, Carol, Lenore Blum, Orit Hazzan, and M. Bernadine Dias. “Culture and Environment as Determinants of Women’s Participation in Computing: Revealing the ‘Women-CS Fit’.” In SIGCSE ‘06. New York: ACM, 2006. Fritz, W. Barkley. “ENIAC: A Problem Solver.” Annals of the History of Computing 16, no. 1 (1994): 25–45. Fritz, W. Barkley. “The Women of ENIAC.” Annals of the History of Computing 18, no. 3 (1996): 13–28. Fuegen, Kathleen, Monica Biernat, Elizabeth Haines, and Kay Deaux. “Mothers and Fathers in the Workplace: How Gender and Parental Status Influence Judgments of Job-Related Competence.” Journal of Social Issues 60, no. 4 (2004): 737–754. Fulmer, John L. “Analysis of Careers for Georgia Youth in Computer Occupations, 1971–76.” In Proceedings of the Eleventh SIGCPR Conference on Computer Personnel Research, 62–79. New York: ACM, 1973. Gearing, H. W. “Selection and Training of Programmers: A Business User’s Approach.” Computer Journal 2, no. 3 (1959): 107–109. Gentry, Grace. “Interview by Jeffrey R. Yost.” August 11, 2008. Charles Babbage Institute, University of Minnesota, Minneapolis. Gibbs, W. Wayt. “Software’s Chronic Crisis.” Scientific American (September) (1994): 86. Gilchrist, B., and B. Weber. “Employment of Trained Computer Personnel: A Quantitative Survey.” Paper presented at the American Federation of Information Processing Societies (AFIPS) Spring Joint Computer Conference, 1972. Goheen, Harry Earl. “Interview by Henry S. Tropp.” August 15, 1972. Computer Oral History Collection, Smithsonian Institution National Museum of American History. Goldfinger, Roy. “New York University Compiler System.” In Symposium on Automatic Programming for Digital Computers, edited by U.S. Office of Naval Research. Washington, DC: Office of Naval Research, 1954. Goldstine, Adele K. A Report on the ENIAC (Electronic Numerical Integrator and Computer). Philadelphia: University of Philadelphia, Moore School of Electrical Engineering, 1946. Goldstine, Herman H. The Computer from Pascal to Von Neumann. Princeton, NJ: Princeton University Press, 1972. Good, Jack, Donald Michie, and Geoffrey Timms. “General Report on Tunny.” Bletchley Park, 1945. Goodwin, Doris Kearns. No Ordinary Time: Franklin and Eleanor Roosevelt— The Home Front in World War II. New York: Simon & Schuster, 1994. Greenbaum, Joan. In the Name of Efficiency: Management Theory and Shopfloor Practice in Data-Processing Work. Philadelphia: Temple University Press, 1979.

232  Bibliography

Greenberger, Martin, ed. Computers and the World of the Future. Cambridge: MIT Press, 1962. Greenwood, Frank. “Some Selection Procedures.” In Proceedings of the Fifth SIGCPR Conference on Computer Personnel Research, 64–69. New York: ACM 1967. Grier, David Alan. “The ENIAC, the Verb ‘to Program’ and the Emergence of Digital Computers.” Annals of the History of Computing 18, no. 1 (1996): 51–55. Grier, David Alan. “The Math Tables Project of the Work Projects Administration: The Reluctant Start of the Computing Era.” Annals of the History of Computing 20, no. 3 (1998): 33–50. Grier, David Alan. When Computers Were Human. Princeton, NJ: Princeton University Press, 2005. Grindley, Peter C. “The Future of the Software Industry in the United Kingdom: The Limits of Independent Production.” In The International Computer Software Industry, edited by David C. Mowery, 197–239. Oxford: Oxford University Press, 1996. Grindley, Peter C. The UK Software Industry. London: London Buisness School, 1988. Grosch, Herbert R. J. Computer: Bit Slices from a Life. Novato, CA: Third Millenium Books, 1991. Grossberg, Blythe. “Elsie Shutt: Pioneer Businesswoman.” Harvard Post, July 20, 1990. Gürer, Denise, and Tracy Camp. “An ACM-W Literature Review on Women in Computing.” Inroads: SIGCSE Bulletin 34, no. 2 (2002): 121–127. Hacker, Sally L. Pleasure, Power and Technology: Some Tales of Gender, Engineering, and the Cooperative Workplace. Boston: Unwin Hyman, 1989. Hafter, Daryl M. “The Cost of Inventiveness: Labor’s Struggle with Management’s Machine.” Technology and Culture 44, no. 1 (2003): 102–113. Haigh, Thomas. “‘Crisis, What Crisis?’ Reconsidering the Software Crisis of the 1960s and the Origins of Software Engineering.” Paper presented at the Second Inventing Europe / Tensions of Europe Conference, Sofia, Bulgaria, 2010. Haigh, Thomas. “Inventing Information Systems: The Systems Men and the Computer, 1950–1968.” Business History Review 75 (2001): 15–61. Hall, Wendy, Lillian Israel, Tracy Camp, Paula Gabbert, Lucy Sanders, and Telle Whitney. “ACM Membership Gender Study.” Paper presented at the Grace Hopper Celebration of Women in Computing, Keystone, Colorado, October 3, 2008. Slides at http://community.anitaborg.org/wiki/index.php/ACM_Membership_ Gender_Study. Harding, Sandra. The Science Question in Feminism. Ithaca, NY: Cornell University Press, 1986. Hayes, Caroline Clarke. “Computer Science: The Incredible Shrinking Woman.” In Gender Codes: Why Women Are Leaving Computing, edited by Thomas Misa, 25–49. Hoboken, NJ: Wiley, 2010.

Bibliography  233

Hendry, John. Innovating for Failure: Government Policy and the Early British Computer Industry. Cambridge: MIT Press, 1990. Hewlett, Sylvia Ann, Carolyn Buck Luce, Lisa J. Servon, Laura Sherbin, Peggy Shiller, and Eytan Sosnovich. “The Athena Factor: Reversing the Brain Drain in Science, Engineering, and Technology.” Harvard Business Review (2008): 27. Hicks, Marie. “Meritocracy and Feminization in Conflict: Computerization in the British Government.” In Gender Codes: Why Women Are Leaving Computing, edited by Thomas Misa, 95–114. Hoboken, NJ: Wiley, 2010. Higher Education Statistics Agency. “HESA Statistical First Release 153: Higher Education Student Enrolments and Qualifications Obtained at Higher Education Institutions in the United Kingdom for the Academic Year 2009/10.” Cheltenham, UK, 2011. Higher Education Statistics Agency. “Resources of Higher Education Institutions 2003/04.” Cheltenham, UK, 2005. Hill, Marion. Bletchley Park People: Churchill’s “Geese That Never Cackled.” Stroud, UK: Sutton, 2004. Hinsley, F. H. “The Influence of Ultra in the Second World War.” In Codebreakers: The Inside Story of Bletchley Park, edited by F. H. Hinsley and Alan Stripp, 1–13. Oxford: Oxford University Press, 1993. Hirsch, Rudolph E. “Maximising the Productivity of Programmers.” Computer Weekly 15 (1973): 6, 22. Hoare, C. A. R. “Programming: Sorcery or Science?” IEEE Software 1 (1984): 5–16. Hoos, Ida Russakoff. “When the Computer Takes over the Office.” Harvard Business Review 38 (1960): 102–112. Hopper, Grace Murray. “Automatic Programming—Definitions.” In Symposium on Automatic Programming for Digital Computers, edited by U.S. Office of Naval Research, 1–5. Washington, DC: Office of Naval Research, 1954. Hopper, Grace Murray. “Compiling Routines.” Computers and Automation 2 (1953): 1–5. Hopper, Grace Murray. “The Education of a Computer.” In Proceedings of the 1952 ACM National Meeting, 243–249. New York: ACM, 1952. Reprinted in Annals of the History of Computing 9, no. 3–4 (1987): 271–281. Hopper, Grace Murray. “Interview by Angeline Pantages.” 1980. Computer History Museum Oral History Collection. Hopper, Grace Murray. “Interview by Uta C. Merzbach.” July and November 1968. Computer Oral History Collection, Smithsonian Institution National Museum of American History. Hopper, Grace Murray. “‘Problem L’ Staff.” Grace Murray Hopper Collection 1944–1946, Smithsonian Institution Research Information System (SIRIS), no. 324. Hopper, Grace Murray. “Summary.” In Symposium on Automatic Programming for Digital Computers, edited by U.S. Office of Naval Research, 148–149. Washington, DC: Office of Naval Research, 1954.

234  Bibliography

Hopper, Grace M., and John W. Mauchly. “The Influence of Programming Techniques on the Design of Computers.” Proceedings of the IRE 41, no. 10 (1953): 1250–1254. Horrell, S., J. Rubery, and B. Burchell. “Unequal Jobs or Unequal Pay?” Industrial Relations Journal 20, no. 3 (1989): 176–191. Hoyle, Joseph C., and Richard D. Arvey. “Development of Behaviorally Based Rating Scales.” In Proceedings of the Tenth SIGCPR Conference on Computer Personnel Research, 85–103. New York: ACM, 1972. Huff, Chuck. “Gender, Software Design, and Occupational Equity.” Inroads: SIGCSE Bulletin 34, no. 2 (2002): 112–115. IBM. “My Fair Ladies.” International Business Machines Corporation, 1957. IBM Archives. “A Selective Chronology of IBM Women in Technology.” n.d. http://www-03.ibm.com/ibm/history/witexhibit/wit_timeline.html. Institute of Electrical and Electronics Engineers (IEEE). IEEE Standard Glossary of Software Engineering Terminology: IEEE Standard 610.12-1990. New York: IEEE, 1990. Jacobs, Eugene H. “Letter to the Editor.” Communications of the ACM 2, no. 7 (1959): 6. Jacobs, Stuart J. “Cognitive Predictors of Success in Computer Programmer Training.” In Proceedings of the Eleventh SIGCPR Conference on Computer Personnel Research, 98–110. New York: ACM, 1973. Jensen, John J. How to Pass Computer Programmer Aptitude Tests. New York: Cowles Education Corporation, 1967. Johnson, Luanne. “A View from the Sixties: How the Software Industry Began.” In From 0 to 1: An Authoritative History of Modern Computing, edited by Atsushi Akera and Rik Nebeker, 101–109. New York: Oxford University Press, 2002. Joint Task Force on Computing Curricula, IEEE Computer Society and Association for Computing Machinery. Software Engineering 2004: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering. IEEE-CS and ACM, New York, 2004. Juncosa, Mario L. “Will You Vote for an Association Name Change to ACIS?” Communications of the ACM 8, no. 7 (1965): 424–426. Kanter, Rosabeth Moss. Men and Women of the Corporation. New York: BasicBooks, 1977, rev. 1993. Keane, John F. “Interview by Martin Campbell-Kelly.” May 3, 2002. Charles Babbage Institute, University of Minnesota, Minneapolis. Kendall, M. G. “The Long Hard Look,” London Times, special computer suppl., September 15, 1967, II. Kennedy, David M. Freedom from Fear: The American People in Depression and War, 1929–1945. New York: Oxford University Press, 1999. Kidder, Tracy. The Soul of a New Machine. New York: Avon, 1981.

Bibliography  235

Kiesler, Sara, Lee Sproull, and J. S. Eccles. “Pool Halls, Chips, and War Games: Women in the Culture of Computing.” Psychology of Women Quarterly 9, no. 2 (1985): 451–462. King, Julia. “Engineers to IS: Drop that Title!” ComputerWorld, May 1994, 1, 119. Klawe, Maria, and Nancy Leveson. “Women in Computing: Where Are We Now?” Communications of the ACM 38, no. 1 (1995): 29–35. Kleiman, Kathy. The Computers: The Untold Story of the Remarkable Women Who Programmed the ENIAC. Documentary preview, 2001, http://eniacprogrammers .org. Knuth, Donald E., and Luis Trabb Pardo. “The Early Development of Programming Languages.” In A History of Computing in the Twentieth Century, edited by Nicholas Metropolis, Jack Howlett, and Gian-Carlo Rota, 197–273. New York: Academic Press, 1980. Kosaraju, Deanna. Email to Janet Abbate, September 16, 2010. Kraft, Philip. Programmers and Managers. New York: Springer, 1977. Kraft, Philip. “The Routinization of Computer Programming.” Sociology of Work and Occupations 6, no. 2 (1979): 139–155. Kubie, Elmer C. “Recollections of the First Software Company.” Annals of the History of Computing 16, no. 2 (1994): 65–71. Kumar, Kuldeep, and Niels Bjorn-Andersen. “A Cross-Cultural Comparison of IS Designer Values.” Communications of the ACM 33, no. 5 (1990): 528–538. Kwolek-Folland, Angel. Incorporating Women: A History of Women and Business in the United States. New York: Twayne / Simon & Schuster Macmillan, 1998/2002. Lander, Rachel, and Alison Adam, eds. Women in Computing. Exeter, UK: Intellect Books, 1997. Lerman, Nina. “‘Preparing for the Duties and Practical Business of Life’: Technological Knowledge and Social Structure in Mid-Nineteenth-Century Philadelphia.” Technology and Culture 38, no. 1 (1997): 31–59. “Letter to the Editor: What’s in a Name?” Communications of the ACM 1, no. 4 (1958): 6. Levin, Roy, and Dave Redell. “Foreword.” In Proceedings of the Ninth ACM Symposium on Operating Systems Principles. New York: ACM, 1983. Levine, Suzanne Braun. Father Courage: What Happens When Men Put Family First. Orlando, FL: Harcourt, 2000. Light, Jennifer S. “When Computers Were Women.” Technology and Culture 40, no. 3 (1999): 455–483. Lively, James K. “Technical History of 6813th Signals Security Detachment.” 1945. Lloyd, Tom. “Steve Shirley and F International.” In Dinosaur & Co.: Studies in Corporate Evolution, 61–79. London: Routledge & Kegan Paul, 1984.

236  Bibliography

Lothridge, Charles D. “Levels of Programmer Jobs.” In Proceedings of the Second SIGCPR Conference on Computer Personnel Research, 13–27. New York: ACM, 1964. Lovegrove, Gillian, and Barbara Segal, eds. Women into Computing: Selected Papers, 1988–1990. London: Springer-Verlag, 1991. Lucena, Juan. Defending the Nation: U.S. Policymaking to Create Scientists and Engineers from Sputnik to the ‘War against Terrorism.’ Lanham, MD: University Press of America, 2005. MacKenzie, Donald. Mechanizing Proof: Computing, Risk, and Trust. Cambridge: MIT Press, 2001. Mahoney, Michael S. “Computer Science: The Search for a Mathematical Theory.” In Science in the Twentieth Century, edited by John Krige and Dominique Pestre. Amsterdam: Harwood Academic, 1997. Mahoney, Michael S. “Finding a History for Software Engineering.” IEEE Annals of the History of Computing 26, no. 1 (2004): 8–19. Mahoney, Michael S. “The Histories of Computing(s).” Interdisciplinary Science Reviews 30, no. 2 (2005): 119–135. Mahoney, Michael S. “Software as Science—Science as Software.” In History of Computing: Software Issues, edited by Ulf Hashagen, Reinhard Keil-Slawik, and Arthur Norberg, 25–48. Berlin: Springer Verlag, 2002. Mahoney, Michael S. “Software: The Self-Programming Machine.” In From 0 to 1: An Authoritative History of Modern Computing, edited by Atsushi Akera and Rik Nebeker, 91–100. New York: Oxford University Press, 2002. Malinovsky, Boris Nikolaevich. Pioneers of Soviet Computing, translated by Emmanuel Aronie and edited by Anne Fitzpatrick and Kate Maldonado, 2010. http:// www.sigcis.org/files/sigcismc2010_001.pdf. Mamrak, S., and J. M. Randal. “An Analysis of a Software Engineering Failure.” Computer Journal 20, no. 4 (1977): 316–320. Marcus, Mitchell, and Atsushi Akera. “Exploring the Architecture of an Early Machine: The Historical Relevance of the ENIAC Machine Architecture.” Annals of the History of Computing 18, no. 1 (1996): 17–24. Margolis, Jane, Rachel Estrella, Joanna Goode, Jennifer Jellison Holme, and Kimberley Nao. Stuck in the Shallow End: Education, Race, and Computing. Cambridge: MIT Press, 2008. Margolis, Jane, and Allan Fisher. Unlocking the Clubhouse: Women in Computing. Cambridge: MIT Press, 2002. Martin, C. Dianne. “ENIAC: Press Conference That Shook the World.” IEEE Technology and Society Magazine 14, no. 4 (1995): 3–10. McGaw, Judith A. “Women and the History of American Technology.” Signs 7, no. 4 (1982): 798–828. McNamara, W. J. “The Selection of Computer Personnel: Past, Present, Future.” In Proceedings of the Fifth SIGCPR Conference on Computer Personnel Research, 52–56. New York: ACM, 1967.

Bibliography  237

Mellstrom, Ulf. “Patriarchal Machines and Masculine Embodiment.” Science, Technology and Human Values 27, no. 4 (2002): 460–478. Menkhaus, Edward J. “EDP: Nice Work If You Can Get It.” Business Automation (March 1969): 41–45. Merchant, Carolyn. The Death of Nature: Women, Ecology and the Scientific Revolution. New York: Harper & Row, 1980. Merton, Robert K. “The Matthew Effect in Science.” Science 159, no. 3810 (1968): 56–63. Milkman, Ruth. Gender at Work: The Dynamics of Job Segregation by Sex during World War II. Chicago: University of Illinois Press, 1987. Minsky, Marvin. “Afterword.” In Vernor Vinge, True Names and the Opening of the Cyberspace Frontier, edited by James Frenkel, 331–352. New York: Tor Books, 2001. Misa, Thomas, ed. Gender Codes: Why Women Are Leaving Computing. Hoboken, NJ: Wiley, 2010. “Mixing Math and Motherhood.” Business Week, March 2, 1963, 86–87. Moser, Nora B. “Compiler Method of Automatic Programming.” In Symposium on Automatic Programming for Digital Computers, edited by U.S. Office of Naval Research, 15–21. Washington, DC: Office of Naval Research, 1954. Muise, Cheryl Arena. “Spotlight on Computations, Inc.” Greater Boston Chapter Association for Women in Computing Newsletter, October 1980, 1. National Academies. Climbing the Ladder: An Update on the Status of Doctoral Women Scientists and Engineers. Washington, DC: National Academies Press, 1983. National Academies, Committee on Maximizing the Potential of Women in Academic Science and Engineering. Beyond Bias and Barriers: Fulfilling the Potential of Women in Academic Science and Engineering. Washington, DC: National Academies Press, 2006. National Academy of Engineering, Committee on Public Understanding of Engineering Messages. Changing the Conversation: Messages for Improving Public Understanding of Engineering. Washington, DC: National Academies Press, 2008. “National ACM Membership Survey.” Communications of the ACM 20, no. 10 (1977): 689–692. National Research Council. Report on a Survey on Training and Research in Applied Mathematics. Washington, DC: National Academies Press, 1956. National Science Foundation. Science and Engineering Degrees: 1966–2006, Arlington, VA: NSF, 2008. National Science Foundation, Division of Science Resources Statistics. “Women, Minorities, and Persons with Disabilities in Science and Engineering: 2011.” Special Report NSF 11-309. Arlington, VA. Tables 5-2, 6-2, 7-2. http://www.nsf.gov/ statistics/wmpd.

238  Bibliography

Naur, P., and B. Randell eds. Software Engineering: Report of a Conference Sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968. Brussels: NATO Scientific Affairs Division, 1969. Nelson, Donna J. “A National Analysis of Diversity in Science and Engineering Faculties at Research Universities.” Rev. ed. University of Oklahoma, Norman, OK, 2007. Newell, Allen, Alan Perlis, and Herbert A. Simon. “Computer Science (Letter to the Editor).” Science 157, no. 3795 (1967): 1373–1374. Nilles, Jack. “MIS and Telecommuting: Friends or Foes?” Uniforum’s IT Solutions (February 1996): 30-32, 34, 36. Noble, David. Forces of Production: A Social History of Industrial Automation. New York: Knopf, 1984. Nuseibeh, Bashar, and Steve Easterbrook. “Requirements Engineering: A Roadmap.” In International Conference on Software Engineering: The Future of Software Engineering, 35–46. New York: ACM, 2000. “Obituary: Dame Hilary Cropper.” Times of London, January 14, 2005. “Ode to the ENIAC.” Chicago Daily Tribune, February 18, 1946, 12. Oldenziel, Ruth. Making Technology Masculine. Amsterdam: Amsterdam University Press, 1999. Ó Riain, Seán. “Net-Working for a Living: Irish Software Developers in the Global Workplace.” In The Critical Study of Work: Labor, Technology, and Global Production, edited by Rick Baldoz, Charles Koeber, and Philip Kraft, 258–282. Philadelphia: Temple University Press, 2001. Oyer, Paul D. “An Approach to Computer Personnel Evaluation.” In Proceedings of the Seventh SIGCPR Conference on Computer Personnel Research, 100–113. New York: ACM, 1969. Page, Gwendoline, ed. We Kept the Secret: Now It Can Be Told: Some Memories of Pembroke V Wrens. Wymondham, UK: Reeve, 2002. Panteli, A., J. Stack, M. Atkinson, and H. Ramsay. “The Status of Women in the UK IT Industry: An Empirical Study.” European Journal of Information Systems 8 (1999): 170–182. Patrick, Robert L. “Selection Starts the Cycle.” In Proceedings of the Seventh SIGCPR Conference on Computer Personnel Research, 7–25. New York: ACM, 1969. Patterson, David A. “The Health of Research Conferences and the Dearth of Big Idea Papers.” Communications of the ACM 47, no. 12 (2004): 23–24. Perry, Dallis, and William Cannon. “Vocational Interests of Computer Programmers.” Journal of Applied Psychology 51, no. 1 (1967): 28–34. Perry, Dallis, and William Cannon. “Vocational Interests of Female Programmers.” Journal of Applied Psychology 52 (1968): 31–35. Poole, Teresa. “The IT Woman.” The Independent, January 5, 2000.

Bibliography  239

Popkin, Gary S. “The Junior College as a Source of Programming Personnel.” In Proceedings of the Ninth SIGCPR Conference on Computer Personnel Research, 130–139. New York: ACM, 1971. Rapoport, Rhona, Lotte Bailyn, Joyce K. Fletcher, and Bettye H. Pruitt. Beyond Work-Family Balance: Advancing Gender Equity and Workplace Performance. Hoboken, NJ: Wiley, 2002. Rector, Robert W. “Statement of Principles.” Communications of the ACM 9, no. 4 (1966): 247. Reinstedt, Robert N. “Summary Report on Nationwide Testing Effort.” In Proceedings of the Second SIGCPR Conference on Computer Personnel Research, 1–8. New York: ACM, 1964. Reynolds, Carl H. “Notes on Estimating and Other Science Fiction.” Computer Usage Company, 1967. Reynolds, Carl H. “What’s Wrong with Computer Programming Management?” In On the Management of Computer Programming, edited by George F. Weinwurm, 35–44. Philadelphia: Auerbach, 1970. Rhodes, Ida. “Interview by Henry Tropp.” March 21, 1973. Computer Oral History Collection, Smithsonian Institution National Museum of American History. Rich, Judith. “Gender Segregation in the Academic Staff of Universities in Great Britain, 1980/81–1993/94.” Economica 66 (1999): 509–531. Ridgeway, Cecilia L., and Shelley J. Correll. “Motherhood as a Status Characteristic.” Journal of Social Issues 60, no. 4 (2004): 683–700. Robertson, Laurie. “Arlington Hall Station: The U.S. Army’s World War II Cryptoanalytic Center.” Annals of the History of Computing 26, no. 2 (2004): 86–89. Robinson, Hugh, Pat Hall, Fiona Hovenden, and Janet Rachel. “Postmodern Software Development.” Computer Journal 41, no. 6 (1998): 363–375. Rockmael, Valerie. “The Woman Programmer: A Subjective Reflection.” Datamation (January 1963): 41. Rojas, Raul, and Ulf Hashagen, eds. The First Computers: History and Architectures. Cambridge: MIT Press, 2002. Rossiter, Margaret W. “The Matilda Effect in Science.” Social Studies of Science 23 (1993): 325–341. Rossiter, Margaret. Women Scientists in America: Before Affirmative Action, 1940–1972. Baltimore: Johns Hopkins, 1995. Rossiter, Margaret. Women Scientists in America: Strategies and Struggles to 1940. Baltimore: Johns Hopkins, 1982. Ryan, John M. It Can Be Done! Newbury, UK: Scope Books, 1979. Salerno, John. “Letter to the Editor.” Communications of the ACM 2, no. 8 (1959): 4–5. Samet, P. A. “The Evolution of Computer Science Teaching and Research in the UK.” Paper presented at the Conference on Computers in Europe: Past, Present and Future, Kiev, 1998.

240  Bibliography

Sammet, Jean. “The Early History of COBOL.” In History of Programming Languages, edited by R. L. Wexelblat, 199–243. New York: Academic Press, 1981. Schiebinger, Londa. The Mind Has No Sex? Women in Origins of Modern Science. Cambridge: Harvard University Press, 1989. Seibel, Peter. Coders at Work: Reflections on the Craft of Programming. New York: Apress/Springer, 2009. Shaw, Mary. “Continuing Prospects for an Engineering Discipline of Software.” IEEE Software, November/December 2009, 64–67. Shaw, Mary. “Prospects for an Engineering Discipline of Software.” IEEE Software, November 1990, 15–24. Shaw, Mary. “Software Engineering Education: A Roadmap.” In International Conference on Software Engineering: The Future of Software Engineering, 371– 380. New York: ACM, 2000. Shirley, Stephanie. “Women in Data Processing.” Management Decision 19, no. 7 (1981): 32–34. Shneiderman, Ben. “The Relationship between COBOL and Computer Science.” IEEE Annals of the History of Computing 7, no. 4 (1985): 348–352. Simard, Caroline, and Elizabeth Bandy. “Grace Hopper Conference 2008 Evaluation and Impact Report.” Anita Borg Institute for Women and Technology, 2009. Slaton, Amy. Race, Rigor, and Selectivity in U.S. Engineering: The History of an Occupational Color Line. Cambridge: Harvard University Press, 2010. “Spectral Lines: Learning from Software Failure.” IEEE Spectrum 42, no. 9 (2005): 8. Spertus, Ellen. “Why Are There So Few Female Computer Scientists?” MIT Artificial Intelligence Laboratory, Cambridge, 1991. Stanley, Autumn. Mothers of Invention. Metuchen, NJ: Scarecrow Press, 1984. Steinberg, Ronnie J. “Social Construction of Skill: Gender, Power, and Comparable Worth.” Work and Occupations 17, no. 4 (1990): 449–482. Sterling, Theodor D., M. Lichstein, F. Scarpino, D. Stuebing, and William Stuebing. “Professional Computer Work for the Blind.” Communications of the ACM 7, no. 4 (1964): 228–231. Storey, William K. “Guns, Race, and Skill in Nineteenth-Century Southern Africa.” Technology and Culture 45, no. 4 (2004): 687–711. Stross, Randall. “What Has Driven Women out of Computer Science?” New York Times, November 16, 2008, BU4. Summerfield, Penny. Women Workers in the Second World War: Production and Patriarchy in Conflict. London: Routledge, 1989. Szyszczak, Erika. “Differences in Pay for Part-Time Work.” Modern Law Review 44, no. 6 (1981): 672–682. Teichroew, Daniel. “Education Related to the Use of Computers in Organizations.” Communications of the ACM 14, no. 9 (1971): 573–588.

Bibliography  241

Tierney, Margaret. “Negotiating a Software Career: Informal Work Practices and ‘the Lads’ in a Software Installation.” In The Gender-Technology Relation: Contemporary Theory and Research, edited by Keith Grint and Rosalind Gill, 192–209. London: Taylor & Francis, 1995. Tomayko, James E. “The Case against Automatic Programming.” Annals of the History of Computing 11, no. 4 (1989): 322–326. Toole, Betty A. Ada, the Enchantress of Numbers: Prophet of the Computer Age. Witney, UK: Strawberry Press, 1998. Trescott, Martha Moore, ed. Dynamos and Virgins Revisited: Women and Technological Change in History. Metuchen, NJ: Scarecrow Press, 1979. Tropp, Henry S. “A Perspective on SAGE: Discussion.” Annals of the History of Computing 5, no. 4 (1983): 375–398. U.S. Department of Commerce, Bureau of the Census. “Nonemployer Statistics,” 2002 Economic Census. Washington, DC: U.S. Government Printing Office, 2002. U.S. Department of Commerce, Bureau of the Census. Statistical Abstract of the United States. Washington, DC: U.S. Government Printing Office, various years. U.S. Department of Education, National Center for Education Statistics. Chartbook of Degrees Conferred: 1969–70 to 1993–94, edited by Project Officer Thomas D. Snyder. Washington, DC: U.S. Government Printing Office, 1997. U.S. Department of Education, National Center for Education Statistics. “Digest of Education Statistics.” Washington, DC: U.S. Government Printing Office, 2007. U.S. Department of Labor, Bureau of Labor Statistics. “Computer Manpower Outlook.” Washington, DC: U.S. Government Printing Office, 1974. U.S. Department of Labor, Bureau of Labor Statistics. “Employment and Earnings.” Washington, DC: U.S. Government Printing Office, 1977–1988. U.S. Department of Labor, Bureau of Labor Statistics. “Occupational Outlook Handbook: Computer Software Engineers and Computer Programmers.” Washington, DC: U.S. Government Printing Office, 2010–2011. U.S. Department of Labor, Bureau of Labor Statistics. “U.S. Working Women: A Databook.” Washington, DC: U.S. Government Printing Office, 1977. U.S. Department of Labor, Women’s Bureau. “Employment Opportunities for Women Mathematicians and Statisticians.” Washington, DC: U.S. Government Printing Office, 1956. Valdez, Maria Eloina Pelaez. “A Gift from Pandora’s Box: The Software Crisis.” Ph.D. diss., University of Edinburgh, 1988. Van Ness, Robert G. Principles of Data Processing with Computers. Elmhurst, IL: Business Press, 1966. Waite, John. “Editing Generators.” In Symposium on Automatic Programming for Digital Computers, edited by U.S. Office of Naval Research, 22–29. Washington, DC: Office of Naval Research, 1954. Wajcman, Judy. “Patriarchy, Technology, and Conceptions of Skill.” Work and Occupations 18, no. 1 (1991): 29–45.

242  Bibliography

Wasserman, Anthony I. “Letter from the First Chairman.” Software Engineering Notes 15, no. 5 (1990): 1–2. Weinberg, Gerald M. The Psychology of Computer Programming. New York: Van Nostrand Reinhold, 1971. Weinwurm, George F., ed. On the Management of Computer Programming. Philadelphia: Auerbach, 1970. Wilkes, Maurice V. “Early Programming Developments in Cambridge.” In A History of Computing in the Twentieth Century, edited by Nicholas Metropolis, Jack Howlett, and Gian-Carlo Rota, 497–501. New York: Academic Press, 1980. Wilkes, Maurice V. “Software Engineering and Structured Programming.” IEEE Transactions on Software Engineering SE-2, no. 4 (1976): 274–276. Wilkes, Maurice V., David J. Wheeler, and Stanley Gill. The Preparation of Programs for an Electronic Digital Computer. 2nd ed. Reading, MA: Addison-Wesley, 1957. (1st ed., 1951) Williams, Elizabeth Phillips. “A Systems Analyst’s Computer Watch: 1943–2003.” IEEE Annals of the History of Computing 24, no. 4 (2003): 27–39. Williams, Joan C., and Holly Cohen Cooper. “The Public Policy of Motherhood.” Journal of Social Issues 60, no. 4 (2004): 849–865. Williams, Kathleen Broome. Grace Hopper: Admiral of the Cyber Sea. Annapolis: Naval Institute Press, 2004. Williams, Wendy M., and Stephen J. Ceci. “When Scientists Choose Motherhood.” American Scientist 100, no. 2 (2012): 138–140. Willoughby, Theodore C., William H. Enneis, Jean M. Palormo, and Wayne W. Sorenson. “Panel: Current Perspectives on Selection Testing.” In Proceedings of the Ninth SIGCPR Conference on Computer Personnel Research, 54–74. New York: ACM, 1971. Yost, Jeffrey R. “Maximization and Marginalization: A Brief Examination of the History and Historiography of the U.S. Computer Services Industry.” Entreprises et Histoire 40 (2005): 87–101. Yost, Jeffrey R. “Programming Enterprise: Women Entrepreneurs in Software and Computer Services.” In Gender Codes: Why Women Are Leaving Computing, edited by Thomas Misa, 229–250. Hoboken, NJ: Wiley, 2010.

Index

Note: Page numbers in italics indicate illustrations. Aberdeen Proving Ground, 16, 17, 24, 26, 36–37 Elsie Shutt at, 123 ACM (Association for Computing Machinery), 59, 75, 158–160, 171 Communications of the ACM, 43, 54, 87, 110 conferences, 160–161, 166, 168, 173 reports, 40, 149 and software engineering, 97, 102, 111 women’s involvement in, 147, 151, 158, 161, 163–166 Aiken, Howard, 13, 70, 197n128 ALGOL, 79, 162 Allen, Fran, 1, 104, 163–164, 169 Alvey Programme, 101, 106–107, 156, 208n119 Aptitude tests, 25, 59–61 employer use of, 45, 48, 50–53 Aspray, William, 91, 146 Association for Computing Machinery. See ACM Automatic programming, 8, 73–75, 97, 198n3 debates over, 81–88 software engineering compared with, 99, 107   Backus, John, 79, 81, 87 Bacon, Jean, 155–156

Bajcsy, Ruzena, 104, 169, 172 Ballistics Research Lab (BRL), 16, 33, 36. See also Aberdeen Proving Ground Bartik, Jean. See Jennings (Bartik), Jean BCS. See British Computer Society Beech, Jean, 11 Bell, Gwen, 164 Berman, Fran, 171–172 Berners-Lee, Mary Lee, 115–116, 214n42 Bilas (Spence), Frances, 17, 30, 36 Blanch, Gertrude, 159 Bletchley Park, 13–16, 21–23, 34–36 gendered division of labor at, 20, 28 Bond, Susan, 162, 214n36 Borg, Anita, 161–162, 165–175 British Computer Society (BCS), 97, 158, 160, 162–163 female presidents of, 141, 164 publications, 59, 110 Brooks, Frederick, 93, 95, 98, 100, 107–108 Burnett, Rachel, 164   Cambridge University, 21, 148, 154– 156, 160, 169 EDSAC at, 13, 54, 78 (see also EDSAC) Camp, Tracy, 2

244  Index

Campbell, Betty, 67 Campbell-Kelly, Martin, 89, 91–93, 107 on software services industry, 121– 123, 133, 139 Carnegie Mellon University, 105, 150 Carver, Doris L., 164 Caughey, Catherine, 22 Civil rights laws, 45, 63, 118, 152 Clapp, Judy, 96, 104, 117, 160 Clippinger, Dick, 123–124 COBOL, 42, 84, 87, 132–133, 156 women’s contributions to, 80–81, 208n126 Codebreaking, 13–16, 42. See also Colossus work process for, 20–22, 25–28 Cohoon, J. McGrath, 146 Colossus, 8, 12–16, 34–35 operators, 11, 20–25, 33, 36, 38 work process for, 26–29 Compilers, 73, 77–88. See also Hopper, Grace Murray women’s contributions to, 103–105, 156, 162, 164 Computations, Inc. (Comp Inc), 113, 123–125, 140–141. See also Shutt, Elsie business model, 128, 131–136 Coombs, Mary, 192n57, 214n42 Cooper, Betty, 60–61, 192n57 Cooper, Deborah M., 164 Cropper, Hilary, 127, 141   Decoding. See Codebreaking Devaney, Marge, 71, 211n9 Dijkstra, Edsger, 99–101, 107 Dollimore, Jean, 220n33 Dollis Hill. See Post Office Research Station Du Boisson, Dorothy, 15, 27   Eckert, J. Presper, 13, 16–17, 26, 37 Eckert Mauchly Computer Corporation, 36, 44 EDSAC, 13, 54, 76–78, 99, 160 “Egoless programming” (Weinberg), 95–96

Elliott Brothers, 116, 121–122 Engineering, 43, 159, 148–149. See also Software engineering as background for programming, 46, 51, 60, 69 high status of, 71, 111, 162–163 masculinity of, 5, 18, 57, 65, 84, 151 as metaphor, 53–54, 57–59, 98–109 English Electric Company, 41, 61–62, 156. See also LEO ENIAC, 5, 8, 35, 103, 123 programmers, 11, 18, 33–38, 80, 159 women recruited for, 20, 23–26, 63 work process for, 29–33 WWII role of, 12–13, 16–17 Ensmenger, Nathan, 6, 90, 93   Fein, Louis, 148 Ferranti, 41, 69, 115 F International (FI), 113–114, 123, 126–127. See also Shirley, Dame Stephanie (Steve) business model, 128–136, 140–141 Flowers, Tommy, 14–15, 34 FORTRAN, 49, 78–81, 116, 132 Freelance Programmers Ltd, 113, 126, 214n37. See also F International; Shirley, Dame Stephanie (Steve) Fritz, Barkeley, 5, 37   Garmisch conference, 97–98, 100– 103, 105 Gentry, Grace and Richard, 134, 213n19 Goldberg, Adele, 161–162, 164 Goldstine, Adele, 25, 30, 33 Goldstine, Herman, 25–26, 29, 33 Grace Hopper Celebration (GHC), 152, 169–175 Graham, Fan Chung, 162 Graham, Susan, 105, 158, 163–164, 169 Greenbaum, Joan, 6, 85 Greif, Irene, 169 Grier, David Alan, 6, 43, 58, 103 Grosch, Herb, 81  

Index  245

Haibt, Lois, 79–80, 116–117 Haigh, Thomas, 6, 89 Hall, Wendy, 164 Hardy, Ann, 52, 63 Harvard University, 13, 24, 44, 70, 78, 148 Harvard Business Review, 39 Hawes, Mary, 80, 103 Hawthorn, Paula, 1, 107, 204n65 Hazle, Marlene, 95–96 Hersom, Bobby, 116, 214n42 Hicks, Marie, 6, 64, 91 Holberton, Betty. See Snyder (Holberton), Betty Hoos, Ida Russakoff, 39, 69 Hopper, Grace Murray, 5, 13, 90, 102–103, 159. See also Grace Hopper Celebration and automatic programming, 75, 81–84, 87 compiler invented by, 78–80 feminine metaphors used by, 67, 70 on job titles, 43–44 as role model, 169–170 Humphry, Kathy, 52–53   IBM, 12–13, 41, 45, 119, 133 “chief programmer team” invented at, 98, 101 FORTRAN created at, 49, 78–79 limits for women at, 63, 104, 134, 163–164 machines, 26, 42, 59, 76, 157 Programmer Aptitude Test, 50–52 recruits women, 1, 55–56, 65–66, 91 software experts at, 81, 87, 94–95, 98 work-family balance at, 116–117 IBM Automatic Sequence Controlled Calculator. See Mark I computer (Harvard) “Ideal worker,” 118, 135, 142 IEEE Computer Society, 159–160 opportunities for women in, 158, 161, 164, 168 and software engineering, 97, 99, 102, 109, 111 Ireland, Eleanor, 21, 27, 33, 35

Jennings (Bartik), Jean, 23, 36, 63, 103, 159 ENIAC programmer, 11, 17, 24, 30–33, 37 J. Lyons & Company, 42, 61. See also LEO Jones, Anita, 169   Kahn, Hilary, 156–157 Kaleda, Laurel V., 164 Kamowitz, Elaine, 125, 133 Keller, Laurie, 100, 104, 116, 152– 153, 163 Kircher, Mary, 56 Klawe, Maria, 150–151, 164 Kosaraju, Deanna, 174 Koss, Adele Mildred, 80 Kraft, Philip, 6, 85, 100   Labor, 3, 6–7, 43, 115, 118 estimating cost of, 122, 138 gendered division of, 18–21, 28, 34–38, 54 market, for programmers, 34, 41, 45, 66, 88, 94 and programming methods, 74–75, 77, 81–85, 111 and software crisis, 89–96 and software engineering, 98, 100, 106–107 Land, Susan K., 164 LEO, 42, 61–62 Leveson, Nancy, 150–151 Lichterman (Teitelbaum), Ruth, 17, 31–32, 36, 159 Light, Jennifer S., 18, 37 Liskov, Barbara, 160–162, 169 Little, Joyce Currie, 58, 157–158, 163, 201n39 Los Alamos National Laboratory, 29, 56, 71, 211n9 Lovegrove, Gillian, 153–155   MacAllister, Homè, 159 MacKenzie, Donald, 100–101 Mahoney, Michael S., 91, 100, 107 Manchester University, 35, 156–157

246  Index

Mark I computer (Harvard), 13, 24, 44, 70 Marrs, Margaret, 69 Mauchly, John, 13, 16–17, 37, 90, 103 Eckert Mauchly Computer Corporation, 36, 44 and ENIAC women, 23, 26, 30–31 Mauchly, Kay. See McNulty (Mauchly Antonelli), Kay McNulty (Mauchly Antonelli), Kay ENIAC programmer, 17, 20, 31–32, 36, 37 on jobs for female mathematicians, 18–20, 23 Menzel, Mary, 211n9 Mills, Judith, 214n42 Minsky, Marvin, 75 MIT (Massachusetts Institute of Technology), 12, 46, 67, 148, 161 MITRE Corporation, 95, 104, 117, 121, 160 Moore School. See also Pennsylvania, University of ENIAC at, 16–17, 37–38 women employed by, 23, 25, 33, 35 Moser, Nora, 80, 84, 103   National Bureau of Standards, 69–70, 97, 159 National Science Foundation, 101, 106, 158, 168 Newman, Max, 14, 21, 25, 28, 34–35 Numerical analysis, 29, 31–32, 54, 83, 148   Open University, 48, 100, 153, 163, 165 Organization and methods analysis. See Systems analysis   Pennsylvania, University of (Penn). See also Moore School computer science at, 148, 162 ENIAC at, 13, 16–17, 23–24, 36 Pollock, Guylaine M., 164 Post Office Research Station, 14–15, 34, 125–126

Programmer aptitude test. See Aptitude tests   Raytheon Company, 1, 123–124, 134 Rees, Mina, 159 Remington Rand, 36, 85–86. See also Sperry Rand Hopper at, 44, 70, 78–80, 82, 87 Rhodes, Ida, 70, 159   SAGE air defense system, 67, 104, 117, 120–121 Sammet, Jean, 65, 81, 103, 163–164, 169n62 Shanesy, Carol, 55–56 Shaw, Mary, 105, 107 Shipp, Karen, 153 Shirley, Dame Stephanie (Steve), 9, 84–85, 119, 164 entrepreneur, 113–114, 121–123, 125–136 management strategies, 138–143 Shutt, Elsie, 1, 9, 56 entrepreneur, 113–114, 119–143 Simons, Barbara, 164 Slater, Lucy, 54 Sloan, Martha, 164 Snyder (Holberton), Betty, 80, 159 ENIAC programmer, 17, 30–33, 36–37 Software crisis, 8, 73, 89–97, 101, 109 and software engineering, 106, 108 Software engineering, 8, 73–74, 83, 145, 158. See also Engineering debates over, 96–111 Shirley’s methods compared to, 132 Software services industry, 61, 119– 123, 125, 130, 141 women in, 113–114, 127, 129, 134 Spärck Jones, Karen, 169, 220n37 Sparrow, Elizabeth, 164 Sperry Rand, 41, 163. See also Remington Rand Spertus, Ellen, 150 Subroutines, 77–78, 80, 82–84, 88 Dijkstra on, 99

Index  247

Systems analysis, 42–43, 65, 83, 125 as job category, 41, 43–44, 69, 88, 135 Systems Development Corporation (SDC), 67, 94, 120. See also SAGE air defense system Systers mailing list, 166–168, 174   Tabulator, 12, 20, 26, 54, 59, 60 Tierney, Gertrude, 81 Turing, Alan, 14, 34, 186n75   UNIVAC, 17, 36, 42, 45, 103, 119 aptitude test, 50 and automatic programming, 84–86 Grace Hopper and, 44, 78, 80   Vaughan Systems and Programming Ltd, 121–122 Vaughan, Dina, 121–122, 129   Wade, Barbara, 125 Wajcman, Judy, 7 Warner, Christine, 164–165 Weinberg, Gerald, 87, 95 Wescoff (Meltzer), Marlyn, 17, 23, 25, 32, 36 Whitney, Telle, 168–169, 172 Wilbur, Sylvia, 48–49 Wilkes, Maurice, 76, 77, 84, 98, 101 Wood, Helen M., 164 Work-family balance, 2, 113–119, 135, 140–143 as motive for entrepreneurship, 124– 126, 128–129, 134–135 as problem for computer scientists, 147, 150–151, 158, 164–165 as problem for programmers, 36, 64, 91 strategies for enabling, 155, 157, 171 Wray, Diane, 192n57 Wrens (Women’s Royal Naval Service), 19, 34, 36 as Colossus operators, 15, 20–23, 25, 27–29 Wyman, Irma, 124   Yost, Jeffrey R., 114, 123