In the session on technology, Pamela Mack said she was at a loss to find a case in which feminism, or a distinctively feminine approach, has improved practice or made for better engineering. What follows is an extended version of a commentary meant at the time to take up her implicit challenge by considering a future case study of a situation still in flux, one in which feminism might still make a difference in ways we can now specify. The field in question is software engineering, but before turning to it I'd like to consider the computer and computing more generally as a case study of gender and technology.

Computing has the advantage of having emerged as an essentially new technology at a definable time and place. Before the creation of the electronic digital computer in the mid-1940s, what we now understand as computing did not exist. Before then, "computer" denoted a person, usually a woman, who carried out calculations by hand or with a mechanical calculator. The work was viewed as clerical: computers followed explicit instructions (usually provided by a male mathematician), and accuracy took precedence over imagination. Indeed, when Turing wanted an example of a "mechanical" procedure, he invoked the human computer, albeit in masculine form.

Perhaps for that reason, the first programmers for the ENIAC were women, as were several of the leading figures in the early development of computing, most notably Grace Hopper. Yet, men soon took over, and leading women became the exception in an increasingly masculine field. Hopper remained highly visible until her death in 1992. Indeed, "Amazing Grace" achieved something akin to canonization in her own lifetime. ⁽¹⁾ Everyone of a certain generation and older has a Hopper tale to tell, and the telling often has a hagiographical tone. Although Jean Sammet did not reach that exalted state of matron saint, she also remained a formidable figure within IBM and the profession, universally recognized for her encyclopedic knowledge of programming languages. One can name others, several of whom have served as President of the Association of Computing Machinery (ACM), but that is perhaps the point: one can name them.

How and why did the field fall to men? Does the answer go beyond the obvious, namely that in computing, as in other fields of war work, women returned to the home, or were directed back to the home, to make room for men returning to the labor force? The women of ENIAC, the first programmers, tell a common story of careers interrupted or ended by marriage and the arrival of children. ⁽²⁾ Or is it a matter of men discovering that programming, unlike calculating, was a challenging, creative intellectual enterprise that promised rewards and reputation? At one of the first conferences on the history of computing, John Backus described the culture of the early programming community:

Programming in the America of the 1950s had a vital frontier enthusiasm virtually untainted by either the scholarship or the stuffiness of academia. The programmer-inventors of the early 1950s were too impatient to hoard an idea until it could be fully developed and a paper written. They wanted to convince others. Action, progress, and outdoing one's rivals were more important than mere authorship of a paper. Recognition in the small programming fraternity was more likely to be accorded for a colorful personality, an extraordinary feat of coding, or the ability to hold a lot of liquor well than it was for an intellectual insight. Ideas flowed freely along with the liquor at innumerable meetings, as well as in sober private discussions and informally distributed papers. ⁽³⁾

3. John Backus, "Programming in America in the 1950s -- Some Personal Impressions", in N. Metropolis et al. (eds.), A History of Computing in the Twentieth Century (NY: Academic Press, 198, 125-135.

The (trans)gendering of the computer

As the field became masculine, so too did the machine. At first, that may not seem puzzling. Given the traditional gendering of machines, what else would one expect of a room full of vacuum tubes and oscilloscopes, even as the tubes disappeared behind metal doors and the oscilloscope gave way to the video display? Yet, two questions immediately arise. First, by the early 1950s programming was emerging as an activity distinct from that concerned with the computer as a physical device. The split was reinforced with the development in the mid-to-late '50s of programming languages and operating systems, both designed to keep the programmer away from the machine. ⁽⁴⁾ In most computing installations, the computer had a room of its own, in which it was tended by designated operators, often women, who mediated between it and the programmers. Academically and professionally, computer engineering took charge of the hardware, while computer science concerned itself with the software, that is, with programming languages, operating systems, and methods of data management. Hence, while continuing cultural icons might explain the masculine character of the computer itself, they do not explain why programming should have been masculinized. The boy's club is not an explanation; it needs explaining.

Second, the personal computer assumed a shape in the late 1970s and early '80s that tied it to cultural icons and activities that in and of themselves seem less straightforwardly masculine. The video screen, keyboard, and mouse invited users to write, to draw, to play games, to communicate. Indeed, the emphasis on the verbal, the visual, and the conversational would seem to have pushed the device more toward the feminine, But apparently, that is not how the culture has viewed it. Indeed, casting the computer in a quite different form does not seem to have changed things that much. Studies since the early '80s have generally found that children of both sexes from kindergarten on identify the personal computer as masculine: it is something for the boys. ⁽⁵⁾ The researchers themselves have found that puzzling, but it may at least help to explain why the fundamental restructuring of the computer industry reflected in the replacement of IBM by Microsoft as the shaping force has apparently done little to alter cultural perceptions of the technology.

The central question seems clear. Computing is readily available public knowledge: anyone can acquire it. The machine is for sale everywhere: anyone can buy it. Any woman who wished to do so could become a computer scientist, computer engineer, or software developer. ⁽⁶⁾ Yet, by any measure, the world of computing includes relatively few women. The reason seems at first equally clear. The door may be open, but the world beyond it does not invite entry. Computing is a masculine world, in which women do not feel comfortable. Yet, that is a restatement of the question, not an answer to it. It does not explain what it means for computing to be masculine and how it became so. Nor does it suggest what a regendering of the world of computing might entail and how it might be accomplished. By the same token, it does offer a first-order reply to the question that shapes this conference: what difference has feminism made? To judge by the literature on women and computing, None. But that is a first-order reply, and it requires some adjustment.

6. Perhaps at this point, I should clarify my perspective. My daughter majored in computer science and music at a research-oriented university and has had a successful career as a software developer. Her experiences as a woman in computing have been a continuing topic of conversation between us for some fifteen years.

Indeed, when one examines the question closely, it fragments into pieces that grow more puzzling as they become more specific. Are we talking about computer science or computer technology? In the latter case, are we talking about the technology of production or about computers out there in "Consumption Junction"? ⁽⁷⁾ It's evident that women have not played, and still do not play, much of a role in computer science or in the design and development of computer systems, whether mainframe, minicomputer, or personal computer. They do seem to be more proportionately represented among the consumers of computing, where their representation would seem to be determined more by their presence in business and the professions than by a particular stance toward computers. But there too computing seems to undermine that presence by making women and their work invisible. All that seems clear. The problem is to explain why and to do so without naturalizing technology or essentializing gender. ⁽⁸⁾

8. Flis Henwood, "Establishing Gender Perspectives on Information Technology: Problems, Issues and Opportunities", in Gendered by Design?: Information Technology and Office Systems, ed. Eileen Green, Jenny Owen, and Den Pain (London/Washington, D.C.: Taylor & Francis, 1993), Chapter 2.

Computing lends itself to the challenge, since the computer as a concept is protean. In principle, a computer can do anything we can describe in certain ways that are limited more in theory than in practice. So in practice computing is what we have made of it since the creation of the computer in the late 1940s and early '50s. ⁽⁹⁾ Whatever one wants to say about such abstractions as the Turing machine, it is hard to know how physical computers and the systems running on them could be anything other than socially constructed. ⁽¹⁰⁾ Computing has no nature. It is what it is because people have made it so.

Those people have been overwhelmingly men. That is a readily verifiable fact. What they have created is overwhelmingly masculine. That is a readily verifiable perception., which one often reads in feminist explanations of the paucity of women in the field. Yet, although writers on the subject of gender and computing all proceed on the premiss that computing is gendered masculine --it must be, else why would it be dominated by men?-- the more closely they look at it, the less clear it is just what makes it so. As Judy Wajcman and others have pointed out, some of those explanations verge on the essentialist, as "masculine" and "feminine" take the pole positions in a set of dichotomies: abstract/concrete, objectivity/subjectivity, logical/intuitive, mind/body, dominating/submissive, war/peace, and so on. ⁽¹¹⁾ Computing generally winds up on the masculine side of each of them. But essentialism is not the only problem here. Under such an interpretation, a feminine form of computing becomes the complete obverse of what now exists, and that seems as unimaginable as it is unrealistic. ⁽¹²⁾ Fortunately, a closer look, both at the dichotomies and at their application to computing, suggests that the solution is not that drastic. To show how, we need first to consider the ways in which efforts to pin down the masculine nature of computing end up blurring the very lines they try to draw. Let us work with three case studies from the recent literature.

12. Or, to take another tack, counterproductive: "It could equally well be that once these newly-discovered [feminine] attributes of flexibility, intuition, etc. are revalued and become sought-after skills in computing, men will be the first in line to demonstrate their competence in the field." Henwood, "Establishing ..", 42-43.

Crossing Boundaries

In "Women's Studies and Computer Science: Their Intersection" ⁽¹³⁾, Thelma Estrin points to convergences between feminist epistemology on the one hand and developments in computing and cognitive science on the other. Aimed at reconciling two disciplines that "both emerged as academic disciplines in the 1960s, with no interaction between them because they evolved along very different paths --one for women and one for men," ⁽¹⁴⁾ her discussion tends to cloud the grounds of their convergence rather than shedding light on them. For, without evident input from women or feminism, a masculine computer science seems by Estrin's own description to have developed precisely the modes of thinking that she and others want to identify as feminine.

14. Estrin, 43.

For example, asserting that "[f]eminist epistemology supports concrete thinking as a valuable tool in our way of thinking", ⁽¹⁵⁾ Estrin makes much of object-oriented programming as a style of thinking in concrete terms. Contrasted with procedural and functional programming,

...object-oriented programming is regarded as a physical model simulating the behavior of either a real or imaginary part of the world (C++). Physical models have elements that directly reflect phenomena and concepts that undermine the canonical position by supporting trends that challenge established methods and encourage working with specific objects. ⁽¹⁶⁾

18. By coincidence Estrin's article is followed in the same special number of Annals by Alison Adam's "Constructions of Gender in the History of Artificial Intelligence", in which the line of thinking for which Lisp has served as primary tool, indeed for which it was designed, is designated as irremediably masculinist. It is hard to aim at Lisp without hitting Logo.

If one considers the history of object-oriented programming in terms of its genealogy, then its proposed empathy with feminist modes of thinking appears all the more problematic. Estrin points specifically to Smalltalk, the language of Alan Kay's Dynabook, aimed at placing the power of the computer in the hands of children for drawing, writing, and creative programming. ⁽¹⁹⁾ But, like C++, Smalltalk itself is also an offspring of Simula, which was designed not for children but for researchers doing systems analysis and simulations at the Norwegian Computing Center in the early 1960s. ⁽²⁰⁾ Within that genealogy, object-oriented programming emerges from the notion of modularity, or the division of a program into subunits which are independent of one another and of any specific context. An early and well known expression of the notion is M. D. McIlroy's proposal in 1968 for "Mass-Produced Software Components", which is filled with analogies to machine tools and redolent with the smell of the machine shop and indeed the assembly line. ⁽²¹⁾

21. M. Douglas McIlroy, "Mass Produced Software Components", in Software Engineering: Report on a Conference Sponsored by the NATO Science Committee, Garmisch, Germay, 7^th to 11^th October 1968 (Brussels: NATO Scientific Affairs Division, 1969), 138-5; repr. in Software Engineering: Concepts and Techniques: Proceedings of the NATO Conferences, ed. Peter Naur, Brian Randell, J. N. Buxton (New York : Petrocelli/Charter, 1976)

While one might think of object-oriented programming as rooted in the concrete, object-oriented design involves a sustained process of abstraction, in which one seeks to characterize the objects as members of classes, which themselves are elements of yet more general classes, so that objects may inherit the properties they share with members of other classes. Thus the object "square" is a kind of "rectangle", which in turn is a kind of "figure", and so on. The result is a hierarchy of classes, another concept not generally associated with the feminine. Deciding on what will be the objects constituting a program and how they are related with one another seems a quintessentially Aristotelian exercise in definition by abstraction. To the extent that abstract, hierarchical thinking is classified as masculine, it is difficult to see how object-oriented design and programming are any less so.

If, then, there is convergence between computer science and women's studies, it does not seem to result from the reshaping of computational thinking by feminist epistemology. What Estrin identifies as common elements have emerged within computing from what would seem to be masculine foundations. If the elements to which she points open computer science to women by making it amenable to their ways of thinking about the world, then it has been open for a long time, at least back to the 1960s, because they are ways of thinking to which the men who created computing themselves aspired.

Tove Håpnes' and Knut Sørensen's study of a Norwegian hacker culture similarly, but in their case intentionally, undermines what earlier seemed certainties about the ways in which computing is masculine. ⁽²²⁾

One of the reasons we became interested in this group was the conclusions from a study of female computer science students. They used the hackers as a metaphor for all the things they did not like about computer science: the style of work, the infatuation with computers leading to neglect of normal non-study relations, and the concentration on problems with no obvious relation to the outside world. ⁽²³⁾ Thus, the hackers emerged as a possibly important example of an extremely masculine technological culture.

25. Håpnes and Sørensen, 189.

Perhaps it does, but then we would have a curious separation of culture from its material base. Something is missing here. Although Håpnes and Sørensen refer at points to specific technical practices, they do not explore the role of the programming environment in enabling or even encouraging the behavior and attitudes they observed. They note that the hackers eschew Pascal and COBOL in favor of C and that they belittle the Macintosh while touting the virtues of their Sun workstations. But it is quite likely not the workstation alone that they are praising, because C does not stand by itself on that platform. It seems likely that the hackers are programming in the Unix environment, which was quite consciously designed to foster certain patterns of behavior both individually and collectively. Since the turn of the '80s, it has been the dominant operating and programming system in academic computing and, as a model at least, in the microcomputer software industry. Indeed, in the form of Linux it has recently begun to eat away at the near-monopoly of Microsoft Windows.

Anyone familiar with Unix will recognize it in the behavior of the Norwegian hackers. Unix began as a system for sharing files and thus for communal work. ⁽²⁶⁾ Although Ken Thompson and Dennis Ritchie provided the basic system and the C language, respectively, the development of Unix was a collaborative effort among a relatively large number of people both at Bell Labs and later at Berkeley. The source files were open to all, and anyone could decide to enhance or modify any part of the system. With that freedom came responsibility in accordance with the rule that whoever touched a routine assumed the task of maintaining it for the others until someone else decided to make a change. Membership in the community meant mutual support.

The guiding metaphor of Unix is the toolbox. Unix is an environment for artisans, who craft software from a variety of small programs that "do one thing and do it well" but also can be linked to one another in sequence or "pipe", each taking input from its predecessor and supplying output to its successor. Many of these programs constitute "little languages" and emphasize the verbal aspects of computing. Unix thus encourages what developers refer to as "rapid prototyping" but what Turkle and others would immediately recognize as "bricolage". Pipes and the little languages make programming an interactive enterprise, allowing the programmer to piece together solutions to problems before committing to a final program. That is what makes it appealing to Håpnes' and Sørensen's hackers, but it is also what ought to make it attractive to Estrin as a programming environment for women.

Unix as a mainstream culture of computing seems to present considerable ambivalence here, and thus provides an interesting perspective from which to view, as a third example, Ulrike Erbs's "Exploring the Excluded. A Feminist Approach to Opening New Perspectives in Computer Science". ⁽²⁷⁾ Erb undertook an empirical study of "[German] female computer scientists, who, in spite of the hacker culture and women's marginalization, have successfully made their way in computer science". She found that a "techno-centered" culture of computing acted as an obstacle to her subjects, who had sought access to the field by way of theoretical computer science:

The interviews show that even among computer scientists it remains vague what it means to be competent in computer technology or to be a '"technical insider": Does it mean sitting all day and night in front of the computer? Does it mean knowing every bit and byte or knowing the latest software? Or does it mean knowing how to construct blinking surfaces? In the interviews it became evident that in fact all this is associated with technical competence, while on the other hand knowledge on [sic] system design like requirements engineering, specification and design of algorithms is not thought to belong to technical competence.

One would like to ask how they feel about Unix. On the one hand, the Unix culture rewards technical virtuosity and fosters rapid prototyping and exploratory approaches to design. On the other hand, it reflects fundamental theoretical concerns. Among those who contributed to it in both spirit and substance are Alfred Aho, John Hopcroft, and Jeffrey Ullman, who teamed in several various combinations to produce standard texts in computer science, including the theory of automata and formal languages, the design of algorithms, and the theory and design of compilers. Those texts can be found in the computer science section of German as well as American bookstores. Other contributors to Unix have written equally accessible standard treatises in computational complexity. Unix is theory-based in ways that make it a model for the approach to computing that Erbs's women claim to admire and that they see as their means of access to the field. And it is both the operating system and the programming environment in which AT&T maintains its Electronic Switching System, the backbone of the U.S. telephone system, designed very much with the user in mind.

Unix aside, Erbs's point quoted above poses another problem for an analysis based on gender. The areas of requirements analysis, specification, and high-level design have formed part of software engineering from its inception in the early 1970s. Since the mid-1980s they have tended to dominate the attention of software engineers, both in attracting its leading practitioners and in forming the focus of what those practitioners consider best practice. No one doubts the crucial role of formal requirements analysis and specification; every textbook in software engineering emphasizes it, and the bulk of the research effort in the field has gone toward the development of tools to facilitate the work. In software engineering as a subdiscipline of computer science, formal methods of requirements analysis, specification, and design have drawn the major share of professional attention and recognition. As far as the theoretical community is concerned, Erbs's women view the field in a way that would be difficult to corroborate by more or less objective evidence of its actual practice. So there is a problem of perception here, too.

That said, it is also the case that one of the dilemmas of software engineering from its beginnings is that what the theoretical community deems best practice is seldom reflected in the way that large software projects have actually been carried out. Studies have repeatedly shown that the most serious and most expensive errors occur in the early stages, in particular in setting down clearly what the system is supposed to do. Yet, they also show that only a small fraction of project time is devoted to those early stages. Most commonly, technical proficiency does indeed take the place of thoughtful analysis and design, and the outcome is often disastrous. But, in principle at least, the discipline deplores the problem. To that extent, Erb's subjects are in the mainstream, not bucking the current.

Software, engineering, and software engineering

Erb concludes her article by urging that

...there is a great need for women's research and in particular for women's research done by female computer scientists. In this way women's studies can help to reveal the excluded and to integrate the excluded in order to enrich computer science by means of the forgotten perspectives. ⁽²⁸⁾

The research of Lucy Suchman and her colleagues on participatory design is concerned, among other things, with situated cognition, or knowledge and skill that are invoked in specific circumstances. They are often tacit and hence go unnoticed or undervalued in studies of use and practice on which the design of computer systems is based. ⁽²⁹⁾ Those studies focus on what can be formulated in general terms: one does not usually computerize this or that traffic control room, but traffic control rooms in general. For historical and cultural reasons, women's work and their ways of carrying it out quite often disappear from view in this move from the situated to the general, e.g. the experience and judgment underlying clerical tasks, or the often critical decisions routinely made by nurses but not allocated to them professionally. This is where Erb sees promise in general. If we look at the professed interests of her subjects, that promise assumes a much more definite shape. We need to back up just a bit to see it.

Between 1955 and 1970, through a pattern of interaction that remains largely unanalyzed, the use of computers spread widely while the computer industry expanded. The ever wider variety of applications, combined with the increasing sophistication of computer systems themselves, put an exponentially growing pressure on programmers to keep pace with the demand. By the end of the 1960s, almost every large-scale programming project had fallen behind schedule, exceeded its budget, and failed to meet its specifications. Software was not keeping pace with hardware. There were never enough programmers, yet managers were learning that, as Fred Brooks put it in his famous Law, "Adding manpower to a late software project makes it later". ^(29a)

The dominant response in the industry was to view the situation as a problem in production, to be solved by some form of engineering. In 1968, that view started on the path to institutionalization with the convening of the first NATO Software Engineering Conference in Garmisch, Germany; a second followed in 1969 in Rome.

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. ⁽³⁰⁾

One can take several different and revealing directions in exploring this situation. For present purposes, three observations may suffice. First, stating the problem so as to make its solution a form of engineering committed practitioners of the new field to historical and cultural models that have traditionally been associated with men. One model was engineering as applied science, which led to sustained efforts to reduce software development to mathematically based programming tools. Another model was industrial engineering, which fostered the notion of the "software factory" along both Taylorist and Fordist lines. Closely allied to the industrial model was the view of engineering as project management, also with its Taylorist forms of organization of production by chain of command. Other models were open at the time, among them architecture and craft practice, but they received little attention.^30a

Second, no woman participated in either conference, although several women have subsequently established a strong presence in the field, precisely in the areas preferred by Erb's women, namely requirements analysis, specification, and design. ⁽³¹⁾ Interestingly, in her account they construe those areas as belonging to computer science, that is, as pertaining to theoretical analysis rather than technical experimentation. Theory, to repeat one of Erb's main findings, provides them with access to a world of computing that they otherwise view as uninviting or even hostile.

One may question, however, whether the upper half of the process has anything to do with computer science or with software engineering on any of its (now) traditional models. It begins, to repeat, with a determination of what is to be modeled, and that involves an understanding not of computers but of the real-world situation in question. It means in particular an understanding of what the people in that situation are trying to accomplish, what they contribute to accomplishing it, and how a computer system would help them to do it better or at least more efficiently. That is not what one learns in studying computer science; that is not what computer science is about. ⁽³³⁾

To accomplish that task requires that one know how to observe and to listen. To take a lead from Suchman, it requires being able to see what certain perspectives render invisible, to hear what certain discourses render inaudible. It places a premium on asking how the system is currently working before dictating how it should work in the future. Here, it seems to me, is where feminism could make a difference to one field of engineering (whether or not it is in fact engineering). Feminist analysis has brought out the ways in which a world built by men hides the ways in which women make it work, and it is the working world that computers must capture if they are going to enhance all our lives.