Tag Archives: programming

What makes software hard?

A couple of years ago I wrote an essay for the IEEE Annals of the History of Computing entitled “Software as History Embodied” in which I addressed the tongue-in-cheek question, first posed by the Princeton historian Michael Mahoney, of “what makes the history of software so hard?” Mahoney himself, of course, was playing on an even earlier question asked by numerous computer programmers, including the illustrious Donald Knuth. In my essay, I focused specifically on the challenges associated with software maintenance, a long-standing and perplexing problem within the software industry (one made all the more complicated by the fact that, in theory at least, software is a technology that should never be broken – at least in the tradition sense of wearing out or breaking down). My answer to Mahoney’s question was that the history of software was so hard because software itself was so complicated. Software systems are generally deeply embedded in a larger social, economic, and organizational context. Unlike hardware, which is almost by definition a tangible “thing” that can readily be isolated, identified, and evaluated, software is inextricably intertwined with the larger socio-technical system of computing that includes machines (computers and their associated peripherals), people (users, designers, and developers), and processes (the corporate payroll system, for example). Software, I argued, is not just an isolated artifact; software is “history, organization, and social relationships made tangible.”

In any case, I was tickled this past week to discover in my archives an early example of one of my “computer people” asking the question “what makes software so hard.” The article is from 1965, and was published in Datamation. The author is Frank L. Lambert, about who I know very little, other than that he was the head of the software group for the Air Force. What I like most about this piece is the way in which Lambert adopts a broad understanding of software. “Software … is the total set of programs” used to extend the capabilities of the computer, and the “totality of [the] system” included “men, equipment, and time.” Like so many of his contemporaries, Lambert saw software as a complex, heterogeneous system. “What made software so hard?,” Lambert asked rhetorically: “Everything.”

Programmer Productivity

In an intriguing post entitled Fact and Folklore in Software Engineering, Laurent Bossavit addressed one of the most persistent memes in software development:

One debate (if it can be called that) which has gone on for too long without a satisfactory resolution concerns programmer productivity and the often quoted “observation” or “fact” that the best programmers are 10 times better than the worst. I will come back to the origins of this observation, but it isn’t quite the topic of this article.

As Bossavit rightly notes, this “fact” about programmer productivity has been circulating for decades, acquiring authority via constant repetition.   It is widely cited as evidence for the special genius of the so-called “super-programmer,” whose skills (innate, not acquired) are vastly superior to the merely average programmer.   In my chapters on “The ‘Black Art’ of Programming” and “Chess players, Musicians, and Mathematicians” I devote a fair bit of space to the ways in which the idea that good programmers were “born, not made” played out in the emerging labor market for computer programmers.  The goal was not, of course, to make any empirical claims about programmer performance, but rather to provide a historical context for a debate that has now spanned several decades.

What Bossavit does with this meme is interesting.  Borrowing from the work of Bruno Latour (one of the patron saints of my own academic discipline), he describes the ways in which data from a single, very limited study gradually become a well-established scientific “fact.”  The original study was undertaken at the Systems Development Corporation (SDC) by the personnel researchers Hal Sackman, W.J. Erickson, and E.E. Grant. It was published in 19681Sackman, Hal, W.J. Erickson, and E.E. Grant. “Exploratory Experimental Studies Comparing Online and Offline Programming Performance”. In: Communications of the ACM 11.1 (1968), pp. 3–11.

SDC was the Rand Corporation spin-off charged with developing the systems software for the SAGE air defense project.  Over the course of the late 1950s and early 1960s, SDC trained (or recruited) thousands of computer programmers.  As one point, SDC alone employed more than three-fifths of the programmers in the United States.  They had, therefore, a huge stake in understanding programming expertise.  “We trained the industry,” SDC executives were later fond of saying, and in many respects they were correct; for the next decade, at the very least, any programming department of any size was likely to contain at least two or three SDC alumni.

The 1968 study examined the performance of 12 (!?!) programmers split between two groups.  Each groups worked in a different environment (one “online”, or interactive, another in a simulated “offline” environment) on a debugging task.  It was not really a study of programmer performance per se, but among their other observations Sackman et al. noted “striking differences” in the performance of different  programmers.  The fastest programmers completed the task 28 times faster than the slowest programmers.  The performance of the most efficient program was, on average, 10 times better than that of the least efficient.  From this the authors concluded (borrowing from a familiar nursery rhyme) that “When a programmer is good, he is very, very good. But when he is bad, he is horrid.”  Despite the obvious limits of the 1968 study, the 10x figure quickly became part of the lore of of the industry.

  • 1
    Sackman, Hal, W.J. Erickson, and E.E. Grant. “Exploratory Experimental Studies Comparing Online and Offline Programming Performance”. In: Communications of the ACM 11.1 (1968), pp. 3–11.

The Programmer’s Coloring Book

In the mid-1960s, the computer industry journal Datamation published a series of parodies of the cult-classic The Executive Coloring Book.  The Executive Coloring book was itself a parody of the self-important man-in-the-grey-flannel-suit managerial culture of the period.

The cartoon above is from my favorite of the Datamation parodies, which was called The Programmer’s Coloring Book.  The book is full of funny little in-jokes for computer programmers, including “See the programming bug.   He is our friend.  Color him swell!  He gives us job security,”  and “Here is an outlook.  Color it bleak,”  and “Here is a flowchart.  It is usually wrong.”  I wish that I had been able to include more such images in the print-version of the book.   They really capture the flavor of what it was like to work as a programmer in the 1960s.

Here is the full version.

Excerpt: Where did all the women go?

The story of the “computer boys” begins, intriguingly enough, with a group of women. Throughout the book the role of female computer programmers is described, as is the process by which computer programming was gradually made masculine. The question of gender in the computing fields, and in academic computer science in particular is still a pressing problem for educators, industry, policy-makers, and society in general.

The following is from Chapter 8: Visible Technicians:

In 1969 the Data Processing Management Association presented Rear Admiral Grace Hopper with its very first “man of the year” award. That a professional society in a technical field would, in this period, even consider awarding its very first major award to a woman seems astounding to modern sensibilities. In the decades since the “ENIAC girls” became the world’s first computer programmers, the computer professions have become stereotypically masculine, and female enrollments in computer science programs have been declining since the mid-1980s. Participation rates for women in the computing fields are a perennial problem for the industry, and this has been the subject of much study and debate for the past several decades.

It was not always thus. As we have seen, women played an early and important role in the history of computing. Some of them became quite influential: in addition to Grace Hopper, Betty Snyder Holberton, Jean Sammet, and Beatrice Helen Worsley, among others, rose to positions of considerable prominence in the early computing industry … However, during this same period the computer programming community was also actively pursuing a strategy of professional development that would eventually make it one of the most stereotypically male professions, inhospitable to most women.

For more information on women in computing, see Gender Codes: Why Women Are Leaving Computing.