All posts by nathanen

New Book: Hybrid Zone: Computers and Science at Argonne National Laboratory, 1946-1992

http://docentpress.com/media/2013/03/yood_cover_layout1.jpgThere have been a number of exciting new books in the history of computing that have been published in the past year. The most recent is Charles Yood’s Hybrid Zone: Computers and Science at Argonne National Laboratory, 1946-1992 (Docent Press, 2013).

The Hybrid Zone arrived in the mail at a timely moment. As part of the recent dedication of Indiana University’s new Big Red II Supercomputer, the current director of Science at the Argonne Leadership Computing Facility of Argonne National Laboratory gave a public lecture on the history and future of computing in the sciences. And so it has been a week of supercomputing all around…

I plan on writing more about Yood’s book sometime in the near future, but for the time being, here is what I blurbed for the book cover:

This book provides an insightful, accessible, and nuanced history of the complex interactions between electronic computing, computer science, and the immensely influential scientific and intellectual practices known collectively as computational science. In Hybrid Zone, Yood has managed to combine deep historical scholarship with a broadly synthetic perspective that will be of interest to scholars, practitioners, and general audiences interested in understanding the relationship between technological innovation, scientific practices, and the social history of computing.

The announcement for the book can be found at Docent Press. Find it on Amazon here.

Fixing that which cannot be broken.

This semester I have been teaching a course on the social and organizational aspects of software development. This is not a history course, but a course aimed at students who are working towards becoming software professionals.

One of the more interesting discussions we had recently was about the significance of maintenance in the software development lifecycle. Software maintenance occupies the majority of the time and expense associated with software development — a fact that continues to surprise and perplex even those with long experience in the software industry. In theory, software should never need maintenance, or at least not maintenance in the conventional meaning of the word. After all, software does not break down or wear out. It has no parts to be tightened or lubricated. Once a software system is working properly, it should continue to work forever, assuming that nothing goes wrong with the underlying hardware. So why all the effort spent fixing something that can never be broken?

I have written about the history of software maintenance elsewhere.1Nathan Ensmenger, “Software as History Embodied.” Annals of the History of Computing (2009), 31(1) The short version of the story is that most software maintenance is not about fixing bugs, but about adapting software to a changing technological and organizational environment. As Richard Canning, one of the first industry analysts to identify and describe the hidden costs of software maintenance, described the situation, most maintenance was a reflection not of technological failures, but of “changes in the business environment” 2Richard Canning, “The Maintenance Iceberg,” EDP Analyzer (1972), 10(10) Because software systems were so inextricably tied to other elements of the socio-technical system, it had to constantly evolve in response to changes in its surrounding environment. It is this interface with other systems that “breaks” and needs to be “maintained.” In this as in many other cases, the adoption of metaphors from traditional manufacturing break down when applied to software development.

In any case, it turned out the literature on software maintenance provided my students with one of the most convincing demonstrations of what Frederick Brooks famously described as the “essential” complexity of software development. Brooks was using the Aristotelian distinction between essence and accident to argue that software was difficult not in its implementation (in other words, because of the difficulty in avoiding bugs) but in terms of its fundamental essence. The complexity of software was unique in that it was never-ending; unlike say, the complexity of physical or natural systems, the complexity of software was arbitrary, “forced without rhyme or reason by the many human institutions and systems to which [software] interfaces must conform.”3Frederick Brooks, *The Mythical Man-Month Addison-Wesley, 1975).

This notion of essential complexity neatly tied together a series of conversations we have had over the course of the semester about the life-cycle of software development, from programming language choice to development methodologies to user-centered design philosophies to documentation and maintenance. I would be the last to argue that the goal of doing history is to learn lessons about the present, but in this case, the relevance of the history of computing to contemporary practice was particularly apparent.

  • 1
    Nathan Ensmenger, “Software as History Embodied.” Annals of the History of Computing (2009), 31(1)
  • 2
    Richard Canning, “The Maintenance Iceberg,” EDP Analyzer (1972), 10(10)
  • 3
    Frederick Brooks, *The Mythical Man-Month Addison-Wesley, 1975).

The Computer Boys meet the Digital Humanities

In the most recent issue of the American Quarterly, a professor of Literature, Communication, and Culture at Georgia Tech named Lauren Frederica Klein has published an interesting review essay that covers The Computer Boys.  The full essay is behind a paywall, but if you have access is well worth tracking down.  I have said before that a good reviewer can reveal things about a book that even the author might not have seen or even explicitly intended.  In this case, Professor Klein situates The Computer Boys in the literature the digital humanities.  This is not necessarily how I had thought of the book, but her reading of the book in this context makes sense, and has given me much to think about.

Of the other books covered in the essays, I was familiar only Wendy Hui Kyong Chun’s Programmed Visions: Software and Memory (in fact, my much-delayed copy arrived in the mail earlier this week) and Lisa Nakamura and Peter Chow-White’s edited volume Race after the Internet.  I assign Nakamura’s work all the time in my courses.   The fourth book, however, was new to me: Debates in the Digital Humanities, edited by Matthew Gold.  All of these are worth a closer look in their own right, but Klein’s essay inspires me to think of the connections between them in new ways. As academics, it is too easy to get lost in our own disciplines.

Here is one of the particularly nice things the review has to say about The Computer Boys:

This is important work for the history of computing, and for the digital humanities as a whole. For even if Ensmenger does not position his study as a prehistory of digital culture, accounts such as his are essential if we are to fully comprehend the historical and technical complexity of today’s digital world.

One of my goals in the book was to make the history of computing relevant to scholars in disciplines other than the history of science and technology.  I am pleased to see that my work can be useful in the context of American Studies and the digital humanities!

 

An Anthropologist Among the Programmers

Although there has been a fair amount of popular writing on contemporary programming culture, there are very few rigorous and sustained academic studies of programming practice.  Gabriella Coleman, an anthropologist at McGill University, researches and writes about hacker culture and communities, and her new book Coding Freedom: The Ethics and Aesthetics of Hacking is out and available for purchase.  She was recently profiled in Wired.

I am a little biased, because Biella is a friend, but her work is absolutely fabulous.  She also has done an excellent job communicating her scholarly work to the general public, and has been widely covered in the media.

Race, Class, and Gender in the History of Computing

A recent article in the New York Times described an innovative vocational training program recently launched by Pathways in Technology Early College High School in Brooklyn, New York.   In this six-year program that provides both a high-school degree and an associate’s degree, students pursue an alternative path towards careers in the computer industry.  The curriculum was developed in part with help from IBM.

The idea that a traditional college degree was not necessary (or even appropriate) for training in the computer fields is not new.   From almost the very beginning of the computer industry, the pressing demand for programmers, and the unique nature of the skill-set that seemed to be required by programmers, caused considerable concern about how to train programmers cheaply and effectively.  Much of the Computer Boys book is, in fact, about the various responses to this perceived problem, which included the widespread use of aptitude testing and personality profiles, as well as the formation of vocational schools.  The resemblance of the history to the program described in the recent NY Times article is not the subject of this particular post.

What struck me most about the NY Times piece was not the article itself but the accompanying images.  All of the students in these images are either black or Hispanic.  In part this reflects the demographics of the Brooklyn neighborhood in which the Pathways High School is located, but the total absence of white faces is a reminder of one of the unanswered questions in the history of computing: namely, what about race and class?   As anyone who has studied any of the social sciences knows, race, class, and gender represent the holy triumvirate of analytical categories.  It is often productive to ask questions about any (and all) of this trinity, because interesting answers almost always result.

In recent years the history of computing has done a much better job dealing with gender.   Race and class, however, are still almost invisible.  When I present on my work on gender and computing, and talk about the ways in which the computer industry, in its infancy, at least, was unusually open to women, I will frequently get a follow-up question about race.  Presumably the same openness and lack of barriers to entry that made programming appealing to women would have made it equally appealing to other minorities, the questioner implies.  This is an excellent question, and I wish I had a better answer…

There is some evidence that computer programming was perhaps more open to non-whites than other technical professions.  Particularly for those who equated “programming” with “coding” (that is to say, low-skilled, largely mechanical labor), the use of ethnic minority workers (like female workers) represented a way to inexpensively increase the output of the “software factory.”  A number of high schools, often in the southern states, started vocational programs aimed at training African-American youth to work in the computer industry.  In fact, in 1967 the New York Times published a piece on a Commerce Department program that is striking similar to it recent 2012 article.  The target of the Commerce Department program was “boys from lower economic levels,” but again the accompanying photo was of a young black man.1 Joseph Loftus, “Commerce Agency Trains Youths on Computers, New York Times,  Aug 13, 1967. A few years earlier, the Times had published another piece whose headline claimed “Computer Seen as a Boon to Negro.”2  William Smith, “Computer Seen as Boon to Negro, New York Times,  Dec 4, 1964  The argument was that although automation might be disproportionately affecting African-Americans, it also potentially promised them new opportunities working as computer programmers: “Computer people are in short supply, and if a company needs a good programmer, they don’t care what his race, creed, or color are as long as he can do the job.”

The language of this last piece is strikingly similar to that used to describe the opportunities for women.   But whereas getting data on women in the computing professions is difficult, getting data on race is almost impossible.  The earliest data I have is from the 1970 census, which noted that, out of 161,337 total programmers, 5,837 (3.6%) were black and 3,559 (2.2%) were Hispanic.   For the formative first few decades of the computer industry, I have nothing but anecdotal data.

It is clear, however, that just as computer programming was made masculine over the course of the 1970s (in the sense that the idealized stereotype of the programmer was transformed from female to male), computer programming also became increasingly white (again, if not in numeric terms, at least as a cultural category).  The sociologist Ron Eglash has a beautiful piece on contemporary attitudes towards race and computing entitled “Race, Sex and Nerds: from Black Geeks to Asian-American Hipsters” that I use all the time in my teaching.  But a larger history of race in computing has still to be undertaken.  Graduate students, be aware!

  • 1
    Joseph Loftus, “Commerce Agency Trains Youths on Computers, New York Times,  Aug 13, 1967
  • 2
      William Smith, “Computer Seen as Boon to Negro, New York Times,  Dec 4, 1964