Category Archives: Extras

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).

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

How many programmers are there?

made with ChartBoot

The chart above shows the Bureau of Labor statistics on programmer employment. I am not convinced that these numbers are at all accurate. Getting reliable data on programmer employment is surprisingly difficult.

To begin with, programmer is a vague category, and it is by no means clear that everyone who worked on “programming” defined themselves primarily as a “programmer.” Secondly, the Bureau of Labor Statistics did not beginning tracking programmers until 1972, and in 1983 and again in 2000 they adjusted their categories and methodologies. For the first ten years, three broad categories (“computer specialists”, “computer programmer”, and “computer analysts”) encompassed everyone working in computing.

By 2000, these categories had expanded to include Computer and information research scientists, Computer systems analysts, Information security analysts, Computer programmers, Software developers, applications and systems software, Web developers, Computer support specialists, Database administrators, Network and computer systems administrators, Computer network architects, Computer occupations, and “all other” computer occupations. This seems to explain the decline in the number of programmers post-2000. Some of them simply got recategorized.

The one person who can’t be replaced by a computer …

… is the person who runs one.

I came across this advertisement for the Electronic Computer Programming Institute (ECPI) in the September 16, 1966 issue of Life Magazine.   It is particularly notable for the way in which it plays on fears of technologically-driven unemployment:   “For all the people the computer puts out of a job, it can put more people into new ones.”

During the mid-to-late 1960s, vocational schools offering training in computing sprung up all over the country, appealing to the massive growth of the computer industry and the desperate need for programmers to develop software for them.  Some of these schools were legitimate attempts to provide much needed training in computing; others were fly-by-night operations that played on vulnerable populations (the un- or under-employed, women seeking to reenter the labor market after taking time off to have children).  All promised a high-paying job after graduation.  Most relied on some form of aptitude testing as an admissions criteria (although many admitted students regardless of their scores, with the sole condition that they were able to pay).  Many did not even provide hands-on time with an actual computer, or at best provided an hour or two of time on a leased machine.1  Edward Markham, “EDP Schools: An Inside View”, Datamation 14:4 (1968)

 By the late 1960s, the flood of vocational schools had become something of a scandal.  Numerous exposes of their less admirable practices were published in the industry literature, and many companies adopted “no vocational school graduates” policies.  The result was frustrating to both aspiring programmers and their potential employers, and highlighted the problematic nature of programmer education and training.  The need for quality programmers was apparent to everyone. But what exactly made for a quality programmer?

 

  • 1
      Edward Markham, “EDP Schools: An Inside View”, Datamation 14:4 (1968)