• Abstract and Figures
• Public Full-text

October 6, 2009 Dear Readers: As advertised, this is work-in-progress. Feel free to rip it, but please do not cite, circulate further, etc, without permission. Since this is part of a larger book project, a note of explanation may be in order. The book-in- progress, Arguments that Count: Physics, Computing, and Missile Defense, 1949-89, analyzes the history of public debate and scientific advising on missile defense in the United States, and shows how the establishment something called “software engineering” shaped that debate. It weaves together three distinct, but mutually influential, narrative threads: the changing place of missile defense in nuclear policy (both official and de facto); the shifting place of physicists as political actors during the Cold War; and finally the rise of computing and software engineering. A brief outline of the book is below. Chapter 7, “The Contrary Networking of Software Engineering,” begins on the next page Chapter 7 is something of a fulcrum for the book. The missile defense debates that take place in chapters 8 and 9 are very different than those that take place in Chapters 5 and 6. Chapter 7 aims to explain how changes in computing contributed to some (not all) of those differences. To some extent, Chapter 7 also aims to show how the mid- 1970s U.S. missile defense project (the most complex software project to that time) influenced software engineering. This is a minor theme in the chapter. All of it is very drafty, but the section on network analysis (see the appendix) is extra, extra drafty. I’ve scattered references to networks throughout the chapter, but figures, charts, tables, and the like are located at the end. Thanks for reading, and I look forward to your feedback! Rebecca Slayton [email protected] Arguments that Count: Physics, Computing, and Missile Defense, 1949-89 (working title) Chapter 7, “The Contrary Networking of Software Engineering” Rebecca Slayton DRAFT: Please do not cite or circulate w/o permission. [email protected] Table of Contents (draft) 1. Between Humans and Machines: Software and the Race Against Surprise Attack (1949-57) 2. Framing Appalling Complexity (1957-63) 3. No Technical Solution? The Making of a Public Debate (1963-67) 4. Physics and Persuasion in the “Sentinel” Debate (1967-1969) 5. Computerniks in the “Safeguard” Debate (1967-72) 6. The Evolving Politics of Complex Technology (1969-75) 7. The Contrary Networking of Software Engineering (1969-81) 8. Technology Limited: Physics in the Star Wars Debate (1983-87) 9. Proving Improbability: The “Nature” of Software for Missile Defense (1983-89) 10. Epilogue (1989-2009) 2 Chapter 7, “The Contrary Networking of Software Engineering” Rebecca Slayton DRAFT: Please do not cite or circulate w/o permission. [email protected] Chapter 7 The Contrary Networking of Software Engineering The air was chilly when Edsmund Dijkstra caught his ride from the airport in Montreal in May, 1974.1 His driver, a manager from IBM, greeted the Dutch computer scientist with a complement: “So you are the world expert on structured programming and chief programmer teams.” The two were en route to a conference on software engineering education, sponsored by IBM at a luxury resort, and the software manager aimed to start on a high note. He missed his mark. Dijkstra concluded that [he] was out in the wilderness,” and “felt very low” by the time they reached the conference. He noted: “The conference was very instructive for me, although learned a lot without which I would have been happier.”2 Indeed, though he coined the phrase “structured programming” in the optimistic spirit that followed the 1968 software engineering conference, by 1974 it had taken on new meanings that Dijkstra found insidious. Whereas Dijkstra wished to structure programs, many managers focused on structuring teams of programmers. Proposals for chief programming teams struck some programmers as an attempt to “deskill” workers and subject them to strict managerial control.3 Worse yet, whereas Dijkstra and other technically-oriented software experts were focused upon perfecting software, managers were often more focused on cost. Dispute between managers and programmers, costs and quality, became frequent themes in a broader debate about the meaning and direction of software engineering in the mid-1970s. As computer experts in industry, academia, and government began to converge in the name of “software engineering,” starting new professional journals, special interest groups, newsletters, 1 History data may be found online at: http://www.almanac.com/weather/history/postalcode/H4J%202K9/1974-05- 03 2 Dijkstra, Edsger W. (1982) Selected writings on computing: a personal perspective: Springer-Verlag New York, Inc.). 3 In 1977, sociologist Philip Kraft drew on David Noble’s and Edward Layton’s classic works in the history of technology when he argued that structured programming was an attempt to control workers in the name of efficiency. Greenbaum, Joan M. (1979) In the Name of Efficiency: Management Theory and Shopfloor Practice in Data-Processing Work (Philadelphia: Temple University Press), Kraft, Philip (1977) Programmers and Managers: The Routinization of Computer Programming in the United States (New York: Springer-Verlag). See also Baker, P. T., “Chief Programmer Team Management of Production Programming”, IBM Systems Journal, (11,1), 1972, pp . 56-71. Available online at: http://www.research.ibm.com/journal/sj/111/ibmsj1101E.pdf 3 Chapter 7, “The Contrary Networking of Software Engineering” Rebecca Slayton DRAFT: Please do not cite or circulate w/o permission. [email protected] and conferences, they were hard pressed to define the field. Practitioners advanced disparate research agendas, including programming languages, environments, tools, formal verification, database management, and complexity measures, to name a few. Conflicts were as frequent as conferences on software engineering. Despite this diversity, there was a guiding hand in the formation of software engineering, and it was the one that Dijkstra despised: the visible hand of management. It is no mere coincidence that the software engineering began to congeal in the mid-1970s with the generous support of the U.S. Defense Department, an institution which was then beset with budgetary and management dilemmas. As we saw in the previous chapter, experts came to recognize software as the “pacing factor” in a deployment of missile defense in the late 1960s and early 1970s. The International Conferences on Software Engineering (ICSE) started up around the time that the “Safeguard” system was deployed in 1975, and as we will see shortly, presenters at early meetings of ICSE were more likely to be associated with missile defense than any other program or system. More generally, defense department managers in the early 1970s confronted opposing demands: cutting budgets while modernizing and unifying computerized command and control systems. A few key computer experts called attention to the growing costs of software, and proved persuasive. By the mid-1970s, the Army, the Navy, the Air Force, and the Defense Advanced Research Projects Agency, had each institutionalized centers of software engineering research and development, justifying it as a cost-saving measure. Economic anxieties marked “software engineering” indelibly with the interests of management. Though economics helped justify and institutionalize new centers of research, software researchers conceived of their new discipline in much broader terms. Ultimately, the most influential publications addressed the challenges of management and technology seamlessly, rather than treating these issues in oppositional terms. Professional meetings were most likely to address issues of design, performance, and management, only occasionally invoking economics explicitly. And while management was a common theme, even one of Dijkstra’s most “pure” research agendas—formally proving the correctness of computer programs—was principally supported by a U.S. Defense Department anxious about securing computer networks. Defense officials kept their eye on the bottom line; networking itself was largely driven by an interest in cutting costs by sharing expensive computing resources. But whatever economic rationales 4 Chapter 7, “The Contrary Networking of Software Engineering” Rebecca Slayton DRAFT: Please do not cite or circulate w/o permission. [email protected] underwrote their projects, software researchers were able to pursue a broader set of research agendas. The result was that software engineering became established as a kind of contrary network in the 1970s. Would-be software engineers did not achieve the ideal-types of professionalism. Though debates about certifying software engineers (and software) were ongoing, software engineers did not succeed in agreeing upon or establishing a means of controlling entry to, or work in, the field. What they did establish was a social and intellectual network of common knowledge and experience about managing—and failing to manage— complex hardware-software systems. 1. Evolving Command and Control Systems: The Software Problem Defense Department interest in software research grew rapidly in the early 1970s, largely in response to efforts to reform the U.S. World Wide Military Command and Control System (WWMCCS). In the late 1960s, three significant failures of the system cost American lives and prompted Congressional investigations.4 These generally underscored the problem of non- standard computer systems

Load more

  55

Copy Link