Recoding gender

I enjoyed the book. It’s a quick survey of early computing and software history, and the lens of gender makes a lot of it new.

A few themes stuck out to me, from my standpoint of 2022:

• Contemporary development, and even agile (by other names) come from feminized sources.
• The distinctions between the activities of plugging, coding, programming, solving, planning, and training; and the roles of “Engineer”, or “Architect” or “Manager” which are largely gendered.
• The feminization of “technical” work of interacting with business machines (e.g. a typewriter, photocopier, etc.) and the perceptual “de-skilling” of those roles despite them being, well, heavily technical.
• Programming productivity gains being gobbled up by increasing complexity…. Well, sometimes… because there is a perceptual emphasis on complex edge-cases rather than the needs of the “typical” business.
• Conference on Software Engineering sponsored by NATO and held in Garmisch, Germany on 7–11 October 1968 was a big deal in the history of programming.

Sure sounds like contemporary collaborative practices:

[Elsie] Shutt’s [of Comp Inc.] 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. 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.

…and Agile:

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.

On productivity and the never-realized goal of getting rid of programming as a specialization:

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 that programs, creating a visible, logical structure that made code faster to produce and easier to maintain, reuse, and share. 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.

An ongoing discussion about what happens.

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 or which was chosen to make a particular claim about the nature of programming. Some managers continued to view programming as creative art or craft—and in a positive sense, rather than as a problem to Be cured by imposing scientific rationality. 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. 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.” 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).
…
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.
….
“For instance, getting your requirements right initially; understanding the materials you’re working with.” 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 engineer ing!” 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.” 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:”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.’ Shaw’s emphasis on users and on real-word, nontechnical factors fits well with the computer-as-a-tool orientation more common among women. Although Engineering as a profession has been highly masculine, engineering as a discipline or philosophy has had wider range of potential meaning.
…
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.