Bulletin of Science, Technology & Society

Bulletin of Science, Technology & Society http://bst.sagepub.com/

The Sociotechnical Boundaries of Hardware and Software: A Humpty Dumpty History Brent K. Jesiek Bulletin of Science Technology & Society 2006 26: 497 DOI: 10.1177/0270467606295002 The online version of this article can be found at: http://bst.sagepub.com/content/26/6/497

Published by: http://www.sagepublications.com

On behalf of: National Association for Science, Technology & Society

Additional services and information for Bulletin of Science, Technology & Society can be found at: Email Alerts: http://bst.sagepub.com/cgi/alerts Subscriptions: http://bst.sagepub.com/subscriptions Reprints: http://www.sagepub.com/journalsReprints.nav Permissions: http://www.sagepub.com/journalsPermissions.nav Citations: http://bst.sagepub.com/content/26/6/497.refs.html

>> Version of Record - Nov 2, 2006 What is This?

Downloaded from bst.sagepub.com at PURDUE UNIV LIBRARY TSS on January 23, 2014

The Sociotechnical Boundaries of Hardware and Software: A Humpty Dumpty History Brent K. Jesiek Virginia Polytechnic Institute and State University This article traces the historical development of the boundaries around computer software and hardware. On one hand, the author documents ongoing discussions about the technical equivalence of hardware and software. On the other hand, he accounts for the stubborn persistence of these terms as markers for two distinct spheres of technology, knowledge, and practice. By using theoretical concepts such as “boundary work” and “coproduction,” the author argues that ongoing efforts to negotiate the boundaries between hardware and software are significantly “sociotechnical” in that they involve both social and technical considerations. The analysis culminates with a discussion of the more recent rise of the “hardware/software codesign” movement. Particular emphasis is placed on the conditions that led to the emergence of codesign and the ongoing challenges faced by its proponents. The article concludes by describing how codesign points toward a more reflexive and socially responsible culture of computer design and use. Keywords: history; computer engineering; computer science; software; hardware; codesign; coproduction

W

hen one attempts to trace the history of the boundary between computer software and hardware, a central tension quickly becomes apparent. On one hand, discussions about the technical equivalence of hardware and software (or roughly comparable terms) have regularly surfaced since the early 1950s. On the other hand, hardware and software have become linked to distinct spheres of technology, knowledge, and practice, and the divide between these two domains has been stubbornly persistent for more than a half century. In this article, I analyze this historical tension through

a series of examples drawn from the history of computing. In developing my account, I use the concepts of “boundary work” and “coproduction” to argue that ongoing efforts to delineate hardware and software are significantly “sociotechnical,” in that they often involve intertwined social and technical considerations. Furthermore, I bring into relief ongoing efforts to question these boundaries, a trend that culminates with the recent growth of the “hardware/software codesign” movement. In addition to discussing some of the conditions that have allowed the codesign approach to gain momentum, I conclude by outlining some of the major challenges this movement faces and the opportunities it reveals.

Theoretical Foundations: Boundary Work and Coproduction In most general terms, my historical account makes novel documentary contributions to two main bodies of scholarship, namely, the history of computing and engineering studies. This article also draws on and informs the field of science and technology studies. More specifically, my analysis is inspired by the literature on coproduction, as perhaps best exemplified by Jasanoff’s (2004) edited volume on the topic. Central to this analytic approach is the assertion that neither the social nor the natural order can be assumed to have explanatory or causal priority in studies of science and technology. Instead, the social and the natural must be viewed as actively “coproduced.”1 The coproduction framework emphasizes the constant intertwining of the cognitive, material, social, and normative, leading us to ask questions such as “What sorts of scientific entities or technological arrangements can usefully be regarded as being co-produced with which elements of

AUTHOR’S NOTE: This article was a winner of the Seventh Annual International Association for Science, Technology & Society Graduate Student Paper Contest. Bulletin of Science, Technology & Society Vol. 26, No. 6, December 2006, 497-509 DOI: 10.1177/0270467606295002 Copyright © 2006 Sage Publications


498 BULLETIN OF SCIENCE, TECHNOLOGY & SOCIETY / December 2006

social order?” (p. 6) and “What are the principal pathways by which such co-production occurs?” (p. 18). To analyze processes of coproduction in the history of computing, I also use the concept of boundary work. As documented by scholars such as Gieryn (1983, 1995, 1999) and Golinski (1998), boundary work involves power-laden efforts to demarcate or “discipline” bodies of knowledge, as well as human actors. And although these authors have largely focused on how these processes play out both within scientific disciplines and between science and nonscience, I contend that this analytic approach is also useful in grappling with technologies and technical disciplines. In fact, this article helps reveal how processes of boundary definition and negotiation intertwine identities, institutions, and bodies of knowledge with technologies and technological design processes.

Historical Foundations: Stored Program Computers and the Machine-Code Boundary The earliest manifestations of what we now call the hardware-software divide emerged in the mid-1940s, when the first large-scale electronic computers were designed, constructed, and put into operation. To begin with, these early computers had much in common with prior calculating and tabulating devices. More specifically, operating the first computers was very “machine oriented” because it involved physically setting switches and wiring up functional subunits. The capabilities of early computers such as ENIAC (the Electronic Numerical Integrator and Computer) were further limited by their sparse electronic memory, which could store only numerical “data.”2 The operations to be performed on those data, on the other hand, were entirely “hardwired.” As noted in many historical accounts, literally “rewiring” a machine to change its operation was time consuming and tedious, a reality that was evident even before ENIAC was fully operational. As a result, new divisions of labor started to emerge around these machines.3 Lessons learned through the construction and operation of ENIAC and its electronic kin provided significant inspiration for the idea of “stored-program” computing. This approach centered on the use of a larger and more flexible machine memory that could store both numerical data and machine instructions. First described in the mid-1940s and implemented in the late 1940s and early 1950s, this innovation quickly became a mainstay of computer design, and it remains dominant today. This technical advance is significant

for a number of additional reasons. For starters, it greatly improved the flexibility of computers, which were increasingly viewed as general-purpose devices. Furthermore, it helped pave the way for an expanding array of programming tools and techniques. As a result of such developments, the distance between computer designers and programmers quickly expanded, with the former increasingly focused on machines and the latter primarily involved with the operation and application thereof.4 Another closely related issue that surfaced in the early days of computer design centered on determining the specific set of “instructions” that should be built into a given machine. On one hand, it was clear that the designer(s) of a computer needed to specify some minimum set of basic instructions for manipulating data and controlling the flow of programs. However, the decision of whether to include any number of more complex functions in the design of a given machine remained largely an open question. John W. Mauchly (1948), who with J. Presper Eckert shared much of the credit for the design and construction of ENIAC, succinctly outlined this design trade-off in a 1947 conference presentation: A decision must be made as to which operations shall be built in and which are to be coded into the instructions. . . . Ultimate choice must depend upon the analysis by the designer of the character of the work to be performed by the machine, the frequency of occurrence of operations, and the ease with which non-built-in operations can be compounded from those which are built in. (p. 205)5

In more contemporary parlance, the built-in operations are generally viewed as part of a machine’s “hardware,” whereas “coded instructions” are referred to as “software.” And as suggested by Mauchly (1948), it was ultimately the responsibility of designers to determine the appropriate boundaries between “machine” and “code,” especially in light of factors such as the intended applications and desired operating characteristics of a given computer. Making such design decisions entailed manifold consequences. Adding new machine instructions might improve the efficiency of a computer and make it easier to use, for example, but it also tended to involve corresponding increases in technical complexity. Conversely, constructing a machine with relatively few built-in instructions might lead to a simple machine design while placing a heavy burden on the programmers who were charged with “compounding” new operations from the small base instruction set.


Jesiek / BOUNDARIES OF HARDWARE AND SOFTWARE 499

Hence, the interests of first-generation computer designers and programmers were increasingly at odds, especially as factors such as efficiency, simplicity, and reliability were pitted against functionality and usability. Yet as the 1950s progressed, it was also apparent that these types of trade-offs were not merely technical in nature. Rather, they were significantly sociotechnical, because they were deeply intertwined with questions about professional identities, disciplinary bodies of knowledge, contexts of employment, and computeroriented educational programs. In the following section, I shed additional light on this theme by analyzing the role and position of two major professional societies in the early computer field.

Demarcating Social, Professional, and Technical Boundaries: The Institute of Radio Engineers Professional Group on Electronic Computers and the Association for Computing Machinery Professional organizations often play an important role in the development of disciplines and fields. In fact, their activities often span and bridge the social and the technical, such as in ongoing efforts to establish professional identities, define the scopes of fields and subfields, codify relevant bodies of knowledge, set standards, and develop curricular recommendations. With respect to the computer field, reviewing the historical development of the Association for Computing Machinery (ACM) and the Institute of Radio Engineers Professional Group on Electronic Computers (IREPGEC) provides a window into these themes. More specifically, I discuss how early efforts to define the scope of these organizations both reflected and reinforced the segmentation of the computer field into two major domains, the first centered on design, engineering, and hardware, and the second linked to applications, users, and programming. The establishment and growth of the IRE-PGEC in the early and mid-1950s reflected the more general efforts of electrical engineers to stake out their own territory in the nascent yet burgeoning computer field. As this movement gained momentum, new terms such as computer engineer and computer designer provided distinct social and professional identities for many of these engineers. These new identities also appeared in tandem with—and became linked to—the sphere of technology designated by the term hardware. Early issues of Transactions of the I.R.E. Professional Group on Electronic Computers clearly reflected these trends.

In the inaugural issue, for instance, the foreword stated: “It is hoped that this issue will be the start of a major publication in the field of digital and analog computer engineering” (Institute of Radio Engineers Professional Group on Electronic Computers, 1952, p. 1). And in a subsequent issue, an editorial indicated that IRE-PGEC members were expected to be principally interested in hardware, adding that papers about the “physical components of which computers are made . . . are the backbone of an engineering journal” (Institute of Radio Engineers Professional Group on Electronic Computers, 1953, p. 1). In addition to providing a simple definition for the term hardware in the context of computing, these statements both codified the link between hardware and “computer engineering” and promoted Transactions as the field’s main journal. This same editorial further outlined the interests of computer engineers by framing programming and applications as largely beyond their scope: “We may think of programming as relating to applications and being outside the sphere of interest of most computer engineers” (Institute of Radio Engineers Professional Group on Electronic Computers, 1953, p. 1). Yet the editors cautiously acknowledged the potential relevance of programming for their audience: It is a fairly recent discovery that, with generalpurpose computers, we can replace hardware by programs. . . . The design of suitable programs is analogous to the design of the computer circuits or the development of the internal logic. We might call it program engineering, for the existence of good programs to assist in running a computer can be as vital to its success as good circuits. We plan to publish papers on a wide range of subjects, including circuits, components, systems, input and output, logic, and “program engineering.” (p. 1)

This passage reveals a central point of tension in the field’s nascent social and technical boundaries. To wit, if hardware could be replaced by programs, and vice versa, on what grounds could the boundaries around computer engineering and computer programming be justified and maintained? As suggested by this line of reasoning, the basis for such a division necessarily required recourse to nontechnical (i.e., social, professional, and political) factors. For instance, framing programming as “program engineering” was one way to bring this topic within the purview of engineers.6 Furthermore, these types of tensions between the technical and nontechnical dimensions of boundary work



can be traced throughout the history of computing. Even more important, these tensions are a significant and persistent source of instability for the computer field, in both historical and contemporary terms. The history of the ACM, which was established in 1947 as the first stand-alone professional society in the computer field, helps fill out this segmentation story. Although the scope of this group initially covered all phases of the computer field, shifts in its orientation can be traced to the early 1950s. And in 1954, ACM president Samuel Williams explained that the Association [for Computing Machinery] has become an important factor in the field of computing machinery. Until the engineering societies became sufficiently interested to struggle with the “hardware,” the Association provided a forum for all phases of the field. Now the Association can direct its efforts to the other phases of computing systems, such as numerical analysis, logical design, application and use, and last, but not least, to programming. (p. 3)

Although Williams’s account downplayed the longstanding interests of electrical engineers in hardware and other areas of computing, his creative framing of the situation helped assuage the jurisdictional tensions that prompted his remarks. In addition to emphasizing the historical position of the ACM, Williams shifted the conversation toward a discipline-building agenda that was focused on less contested areas, such as numerical analysis, applications, and programming. Subsequent leaders of the ACM followed a similar strategy. In late 1955, for instance, mathematician Alston S. Householder (1956) explained in a presidential address that “there are active groups in the IRE and the AIEE [American Institute of Electrical Engineers] concerned with componentry and construction, and the ACM is restricting its sphere to that of the effective use and application of those machines” (p. 1). Yet Householder followed earlier commentators by acknowledging that the major segments of the computer field might not be split so cleanly into two separate spheres: Design, construction, and use are but points on a continuous spectrum since clearly a designer must have a use in mind, and a user, if he is to be intelligent, must know something of the design. But ACM concerns now fall largely in the applications region of the spectrum. (pp. 1-2)

Like many of his colleagues in computing, Householder clearly recognized the tensions and complexities that

came with aligning the activities and interests of a professional society and its members with the larger social and technical boundaries of the field. Yet as the 1950s wore on, the ACM’s presence at one end of the computing “spectrum” was evident in its focus on mathematics, programming, theory, and algorithms. When mathematician Richard Hamming took over as ACM president in 1958, he suggested that the group had given up its interest in computing machinery and was instead largely acting as a point of common ground for mathematicians, logicians, and users (Akera, 1998, p. 593). And just as the boundaries between the major professional organizations were being worked out, others were commenting on how the field’s emergent social and professional divisions were related to the ongoing design and development of actual computer technologies.

Computer Design: Vanguards and Critics Evidence culled from conference proceedings and journals provides important insights regarding the evolving relation of machine designers and programmers. To begin with, it is worth noting that the tentative development of a distinct field of computer engineering in the early 1950s was accompanied by ongoing efforts to position engineers as the principle vanguards of computer design. At the first Joint Computer Conference in 1951, for example, Bell Labs engineer W. H. MacWilliams delivered a keynote address in which he explained that a major objective of the meeting was to assess the adequacy of the designs of present working high-speed digital computers in order to point out the direction in which computer design should go, to make computers best for the jobs that they have been doing and for the jobs that they will have to do. This is basically an engineering or design objective, but it is clear that it also involves the users in an important way. This is a meeting of both builders and users, all of whom are actively interested in the field. (p. 5)

This remark is significant for at least three major reasons. First, it reveals the extent to which computer builders and users were being portrayed as increasingly distinct groups, even in the early 1950s. Second, it hints at the close identification of computer builders as engineers. This theme was also reflected in the topical orientation of the conference toward the “engineering aspects of computing,” as well as MacWilliams’s suggestion that “computer engineers” were the primary conference audience. And third, this passage reveals



that computer builders were being positioned as the main arbiters of computer design decisions. But even as a new class of computer-oriented engineers both articulated their hardware- and designoriented identity and qualified their relationship with the domain of programming and applications, mathematicians and other computer “users” were surfacing as increasingly vocal critics of computer design trends. In a 1953 article coauthored with computer pioneer Grace Murray Hopper, Mauchly revisited the designprogramming relationship, while outlining the major divisions of labor that were growing up in the computer field. Suggestively titled “Influence of Programming Techniques on the Design of Computers” (Hopper & Mauchly, 1953), the article framed design engineers as largely concerned with circuits and hardware and programmers mainly focused on “applications” (p. 1250). In addition to providing further evidence for the boundaries that were forming around the identities and activities of programmers and computer designers, Hopper and Mauchly (1953) emphasized that the relationship between these two groups was “by no means a static one” (p. 1250). They also explained that “the development of new techniques in programming may have as profound an influence on computer design as would be produced by an entirely new type of memory or switching element” (p. 1250). And following in the footsteps of prior commentators, they pushed computer designers to grapple with the concerns and techniques of programmers: “Certainly the programmer must help the engineer in evaluating proposed engineering plans” they stated, adding that he or she “can often suggest possibilities for the engineer to consider. Sometimes a relatively minor design modification can result in savings in programming” (p. 1250). In the remainder of the article, Mauchly and Hopper discussed how a number of programming developments, such as the use of subroutines, might inspire improvements in computer design. In a 1953 article on the topic of “compiling routines,” Hopper worked in similar directions.7 Noting that various techniques could be used to tailor generalpurpose computers for particular applications, she once more stressed the need for close cooperation between computer builders and users. As Hopper explained, “it is desirable that programmers work side by side with logical designers and engineers at the time that the design of a computer, large or small, is begun” (pp. 1-2). Yet these early calls for closer cooperation between engineers and programmers were largely confined to a small circle of commentators, many of

whom happened to be mathematicians and programmers, not engineers.8

Building “Better Computers” Mathematician and computer programmer John W. Carr III surfaced in the 1950s as another outspoken commentator on the types of issues discussed by Mauchly and Hopper. In fact, his efforts to grapple with many of the major issues facing the computer field led him to articulate critiques and recommendations that remain broadly relevant today. One of his earliest commentaries was delivered at the 1956 Eastern Joint Computer Conference. Although the talk was wide ranging, Carr’s (1956) remarks about the growing gulf separating computer designers and users are particularly relevant for the present analysis. As explained by the author, an “artificial wall” or “artificial barriers” had surfaced between the “logical program designer and logical hardware designer” (p. 147). He added that the sparse coverage of programming topics at the conference reflected a widespread lack of communication between computer designers and users. And according to Carr, this problem was intertwined with other issues, including growing concerns about the supply of computer-oriented personnel and ongoing declines in university research and educational activities in many areas of computing. In fact, he suggested that universities could play a pivotal role in ameliorating these problems. Carr (1956) concluded his presentation with a bold vision for the computer field that clearly blurred extant social and technical boundaries. In the technical sphere, he described how cutting-edge computers, such as the Univac LARC and IBM STRETCH, were being designed as “integrated systems” from the “outside in” (p. 149). As Carr explained, this “integrated systems approach” took “the external language of communication as the starting point” and used “automatic programming techniques in carrying the language into the middle of the machine” (p. 149). This novel outlook, in which applications and higher level machine languages drove machine design, was quite unlike the dominant culture of computer design at the time, which involved the commercial development of general-purpose stored-program computers with increasing speed and reliability, but without fundamental innovations in design or functionality. In terms of the field’s social dimensions, Carr (1956) echoed Hopper when he called for improved communication. He more specifically put forth the



idea of small meetings that would bring diverse computer specialists into closer contact. As Carr explained, such events, which might include 10 to 30 persons participating in meetings, and which might be scheduled in tandem with major conferences, could potentially transcend extant organizational and occupational barriers by bringing together “logical designers with programmers, circuitry personnel with automation specialists, language specialists with programmers, and so on” (p. 150). As suggested by this overview, Carr’s calls for “integration” demanded a blurring of social and professional, as well as technical, boundaries. Others were performing similar types of boundary work around this time. Mathematician Saul Gorn, for instance, also argued against the a priori boundaries that had grown up around the spheres of hardware design and programming. In a letter to the editor published in the Communications of the ACM in early 1958, Gorn noted the “equivalence of hardware and programming” (p. 2). And in a 1959 conference paper preprint, Gorn similarly explained, “The point of view expressed in this paper makes more tangible two principles accepted intuitively by many programmers and logical designers. They are a) the equivalence of formal languages and machines, b) the equivalence of programming and hardware” (p. 25-1). Yet in spite of this hypothetical equivalence, Gorn (1958) acknowledged an important associated question, namely, “How much [structure] should be in the hardware and how much the job of programs?” (p. 3). Emphasizing the importance of flexible machine structures, Gorn (1958) provocatively added, Since it is a user’s world, the combination of machine and compiler is the “machine” we are really interested in. The designers of automatic coding systems must therefore be considered among the machine designers, and should be involved before the hardware designers have finished their plans. The pioneers in automatic coding were well aware of the identity of compilers and machines. Others need constant reminding. (pp. 3-4)

Although only a tentative call for change, Gorn’s argument for including compilers as within the province of computer design clearly challenged the dominant position of engineers as vanguards of computer design. Furthermore, his remarks suggested that shifting from a “machine-oriented” to “user-oriented” perspective might demand accompanying revisions in the computer field’s major social and technical boundaries. In subsequent writings, Carr extended his earlier remarks and echoed many of Gorn’s (1958, 1959)

ideas. In a 1962 piece titled “Better Computers,” Carr noted a widespread lack of imagination and new ideas in computer design. Taking aim at “designer conservatism,” he added that “the user is restricted almost completely to the original limited concepts of problem-solving capabilities bestowed on the machines by their designers, rather than a more global view of the problem” (p. 158). Suggesting that this issue was exacerbated by the different work locations of designers and programmers, Carr added, Hardware specialists often propose solutions to important technical problems which involve a relatively small effort by the logical designer, but leave the bulk of actual implementation to the programmer. These men may never have met, and probably don’t even belong to the same organization. (p. 159)

But Carr’s barbs were by no means limited to designers and engineers, and he went on to argue that the “vested interests” of programmers often led them to oppose changes in machine configuration that might threaten their job security. In other words, making machines easier to use might eliminate much of the detailed preparatory work and coding that was at the heart of the programmer’s occupational niche. Once again, the problems identified by Carr clearly involved intertwined social and technical factors, ranging from the interests of various computer professionals to differences in their actual physical working locations. In a 1965 article, Carr forcefully critiqued both computer programmers and designers for failing to recognize that “programming is equivalent to (not ‘analogous to’ or ‘similar to’) building a machine, and not only that, to building a machine in a certain orderly fashion” (p. 16). Invoking a rather suggestive metaphor, Carr noted the pressing need for combining “stored algorithms (programs) and equipment algorithms (machines)” in a more “organic” whole (p. 17). He also described a number of remaining problems in the area of “intercommunication,” especially in terms of the gap between programming theory and practice. As suggested below, the idea of a more “integrated” or organic approach to computer design and computing was attracting wider interest around this time. However, an array of stubborn barriers stood in the way of realizing this vision.

The Hardware/Software Trope Although Carr and Gorn offered convincing arguments that “machines” and “programs” were



equivalent—at least in hypothetical, technical terms—their perspectives were clearly shaded by their theoretical emphasis on “algorithms” and “mechanical languages.” Yet their efforts to call technical boundaries into question frequently hinted at the social and professional aspects of the problem. In fact, the full sociotechnical character of the computer field was increasingly couched in terms of hardware and software. Scientist John W. Tukey is often credited with the first published use of the latter term (Shapiro, 2000). In a 1958 journal article, Tukey stated, “Today the ‘software’ comprising the carefully planned interpretive routines, compilers, and other aspects of automative programming are at least as important to the modern electronic calculator as its ‘hardware’ of tubes, transistors, wires, tapes and the like” (quoted in Shapiro, 2000, p. 69). Tukey’s software appellation succinctly captured an increasingly expansive domain of the computer field, and it served as a convenient foil to hardware. As a result, the term quickly caught on. In fact, a 1961 editorial published in the wellknown trade-magazine Datamation described the computer field’s major sociotechnical boundaries by juxtaposing the terms software and hardware: Although there is considerable mutuality of concern in their ultimate objects, “the advancement of computer technology and application,” hardware personnel and their software peers have long been widely separated by geography, education and interest, and all that is written and said has not as yet made one head out of Humpty and Dumpty. . . . Perhaps, when the seemingly insurmountable hurdles are charged for the last time, it may suddenly appear that Humpty Dumpty is after all, a single entity and must be fitted properly together to continue sitting high on the wall. (“A Datamation Staff Survey,” p. 36)

Although it is not clear whether the Humpty Dumpty metaphor in this evocative passage refers to computer systems, computer-oriented workers, or even the computer field as a whole, this allusion is particularly effective because it hints at the full range of sociotechnical dynamics that were in play at the time. That is, this passage links two general spheres of technology, denoted by the terms hardware and software, with two distinct classes of computer professionals who often worked in different locations and possessed different educational backgrounds and interests. Yet this editorial remark also challenged these boundaries by hinting at the benefits of some sort of unification or integration.9

Similar examples abound. At the 1963 Fall Joint Computer Conference, for example, separate sessions called “Software for Hardware Types” and “Hardware for Software Types” provided further evidence for the extent to which software and hardware were increasingly linked to different professional and disciplinary identities, bodies of knowledge, and cultures of design. Advertisements from major companies in the computer field, on the other hand, evoked the hardware-software schism while calling it into question. For instance, a 1962 ad from Burroughs Corporation echoed Carr as it queried, “When will a computer manufacturer design a system so that hardware and software—including operating system, programming languages and compilers— are completely integrated?” (p. 14). And a 1964 advertisement from Mesa Scientific Corporation even more suggestively declared that “Mesa Men now come in two convenient types: Software . . . and Hardware!” (p. 45). In addition to calling attention to a perceived gulf between these two domains, the ad hinted at the company’s work in overcoming this barrier. More specifically, it emphasized the ability of Mesa’s “integrated software/hardware team” to both “reduce software/hardware interface problems” and “optimize software/hardware trade-offs” (p. 45). In addition to echoing earlier calls for integrated approaches to computer development, this passage forcefully reveals the extent to which the boundary between software and hardware was as much about “men” as it was about machines. Yet despite the rhetoric offered up by companies such as Mesa, it would be many years before truly integrated approaches to software and hardware design were on the horizon.

From “Tar Pits” to Integrated Systems Design Although a comprehensive review is beyond the scope of this article, the tensions between integration and fragmentation in the computer field have largely persisted in more recent decades, albeit with some interesting variations and contradictory trends. For instance, it is difficult to ignore the two major computer-oriented curriculum projects that got under way in the 1960s. The first was largely spearheaded by the ACM and gained principal notoriety through “Curriculum 68,” a set of recommendations focused on computer science programs and departments (ACM Curriculum Committee on Computer Science, 1968). In contrast, the activities of the COSINE Committee, which was composed largely of electrical engineers, initially promoted the development of computer



science programs within electrical engineering departments (COSINE Committee, Commission on Engineering Education, 1967, 1968). However, this group gradually shifted toward the promotion of more hardware-oriented degree programs and courses in the area of computer engineering (Coates et al., 1971; COSINE Committee, Commission on Engineering Education, 1970). This move reduced friction with the ACM, but it reinforced the schisms between hardware and software, between computer scientists and computer engineers. By the mid-1970s, it was evident that the continued development of separate educational pathways for computer scientists and computer engineers was once again promoting a segmentation of the computer field into two distinct spheres. In fact, a number of electrical engineers suggested that this trend was highly problematic. In a December 1975 issue of the journal Computer, published by the Institute of Electrical and Electronic Engineers (IEEE), guest editors David Irwin and C. V. Ramamoorthy noted that “from the educator’s point of view, perhaps no problem is so apparent as that of overcoming the dichotomy between computer science and computer engineering” (p. 27). And in another article in the same issue, engineer Michael Mulder (1975, p. 28) used the evocative image of the “tar pit” to describe the difficult meshing of computer science and computer engineering curricula. Yet in other contexts, forces of integration appeared to be at work. Talks of merging the IEEE Computer Society and the ACM in the early and mid-1970s once more raised questions about the advantages of replacing two significantly overlapping professional groups with a single organization (“Should We Merge?” 1972). And around this same time, other commentators reiterated the idea that the technical divide between computer software and hardware was anything but fixed or easily identifiable. This view was reflected in Structured Computer Organization, a textbook authored by computer scientist Andrew Tanenbaum (1976). In an introductory chapter that summarized the historical development of computer organization and architecture, the author cleverly noted that “one man’s hardware is another man’s software,” and he went on to describe the boundary between computer software and hardware boundary as “arbitrary and constantly changing” (p. 11). Still others were once again looking for ways to overcome the hardware-software schism in the actual practice of computer system design. In a 1975 paper, researchers C. W. Rose and M. Albarran noted the long-standing tendency for the design of hardware and

software to proceed “quite differently and separately” (p. 421). Yet they noted two major trends that were upsetting the status quo. The first of these centered on new technological developments that were providing system designers with the ability to implement a wide variety of functions “in either hardware, software, or a combination of both” (p. 421). The second trend, which the authors described as more “philosophical” in nature, centered on new design methods that were systematic, hierarchical, and capable of dealing with multiple levels of abstraction using a common design language. On the downside, they noted a number of difficult limitations in existing software and hardware design tools, including a lack of suitable hardware description languages and an overall inflexibility with regard to determining the boundaries between software and hardware. As an alternative, they called for the development of a “computer system description language” that could accommodate the hierarchical description of both hardware and software. Their own LOGOS design environment was offered as a tentative step toward a system that could help automate the design of “hierarchical, integrated hardware/software systems” (p. 429). Although that particular paper looked like an important step toward a more integrated approach to computer systems design, its immediate impact appears to have been marginal. As suggested by other commentators, the dominance of “layered” and “hierarchical” models of computer systems architecture through the 1970s may have hampered these alternative efforts. In fact, the dominant culture of computer design at the time tended to either insulate hardware and software specialists from each another or position engineers as the vanguards of computer design decisions. It would take roughly a decade before some of these types of barriers would begin to fall.

The Hardware/Software Codesign Movement Although the phrase “hardware/software codesign” can be traced back to at least 1985, the concept gained significant momentum from the early 1990s onward. By some measures, codesign has attracted a great deal of attention in a relatively short span of time. Many hundreds of papers on the topic have been published over roughly the past decade, and a search of the ACM’s and IEEE’s archives reveals increasing interest in this topic. In addition, the First International Conference on Hardware-Software Codesign was held in 1992, and international workshops and conferences



dedicated to codesign have been held annually since 1996. These events continue to expand in both size and scope. In most general terms, a central tenet of the codesign approach to developing computers centers on the idea that the design of specialized systems must start with no a priori boundaries around software and hardware. A 1991 article on the topic provided one early and rather succinct description of the how and why of this approach. Authors David Franke and Martin Purvis began by outlining the dominant image of the computer design process. “Computer systems development has been ordinarily characterized,” the authors explained, “by the notion that hardware engineers supply general-purpose computing systems, which are then programmed by software engineers” (p. 344). The authors went on to describe the relative independence of software and hardware development activities under this model, and they suggested that layered or hierarchical models of computer architecture create an environment in which software specialists can avoid grappling with “low-level” hardware concerns. However, Franke and Purvis (1991) discussed how a number of recent technological developments made it both feasible and desirable to call into question the boundaries around hardware and software engineering. As suggested by the title of the paper, Franke and Purvis proposed an alternative approach to computer design that “combine[d] the hardware and software perspectives from the earliest stages of the design process” (p. 344). In a more recent paper, computer scientists Micaela Serra and William Gardner (1998) offered a useful summary of four key characteristics of the codesign approach: the cooperative design of hardware and software components; the unification of currently separate hardware and software paths; the movement of functionality between hardware and software; the meeting of system-level objectives by exploiting the synergism of hardware and software through their concurrent design. (p. 1)

Codesign proponents point to a number of advantages of this model, and many of these have broad appeal in the profit-motivated private sector. In terms of the design process, for example, codesign may significantly streamline the coordination of large system design projects, leading to reductions in development time and cost. Codesign may also lead to “better” technologies, at least in terms of technical metrics such as performance, reliability, and/or flexibility.

As suggested by this overview, hardware/software codesign shares much in common with earlier historical movements. Hence, one might wonder why something like codesign failed to gain traction earlier. After all, the preceding analysis shows that the interchangeability of hardware and programs was recognized in as early as the 1950s, and the topic of hardware-software equivalence has been regularly discussed for decades. But during the 1980s, a unique confluence of trends helped enable the emergence of a more recognizable movement of codesign proponents and practitioners. On rare occasion, these individuals even note that their work is a continuation of prior efforts. In an introduction to the 5th International Workshop on Hardware/Software Co-Design, for example, the workshop chairs explained that “designers have practiced co-design since the first microprocessors were used for implementing digital control” (Ernst & Borriello, 1997). Following the typical outlook of technologists, many contributors to the literature on codesign are quick to point out the numerous technical trends that helped set the stage for their efforts. Some relevant and oft cited developments include • • • •

the increasing diversity, complexity, and number of embedded systems in use or development; the growth of hardware development languages, largely in tandem with very large scale integration (VLSI)10 technologies; the development of computer-aided design (CAD) systems that support the design of both software and hardware; and the emergence of programmable chips, such as application-specific integrated circuits.

Yet we might be wary of overemphasizing technological factors as we account for the rise of codesign. As many scholars have taught us, such expressions of technological determinism are both rampant and easy to debunk. Indeed, the preceding overview of the pioneering work by Rose and Albarran suggests that by at least the mid-1970s, some of the pivotal technological and philosophical developments were starting to lead toward new design approaches, and these had much in common with codesign. Furthermore, one cannot help but notice other trends that were afoot around the time that codesign emerged and gained its initial momentum. One prominent example centers on the work of a joint ACMIEEE task force, which was formed in the late 1980s to develop a single set of curricular recommendations for what the committee eventually dubbed “the discipline



of computing” (Tucker, 1990). In 1989, one of the group’s first reports defined computing as “a technological-oriented discipline whose fundamentals are in mathematics and engineering” (Denning et al., 1989, p. 9). In addition to identifying nine major topical areas that were at the core of this proposed discipline, the authors countered persistent tendencies toward fragmentation by framing computer science as principally concerned with “theory” and “abstraction,” and computer engineering as largely concerned with “abstraction” and “design” (p. 12). As suggested by this overview, a common concern with abstraction provided a foundational unity for the diverse phases of the field. The committee’s ambitious vision for a more integrated “metadiscipline” of computing therefore looked like another important step toward overcoming the social and technological rifts that had long persisted in the computing fields. Furthermore, it is highly plausible that the Computing Curricula 1991 (CC1991) effort both reflected and reinforced a culture of integration in the computer field that helped enable the emergence and growth of the codesign movement.11 This thesis is further supported by the observation that many codesign researchers had (or have) university affiliations or appointments. Perhaps Carr’s observations ring true: Universities do indeed play a crucial role in stimulating research and development activities at the cutting edge of computing. Yet as the work of the aforementioned Serra and Gardner (1998) reveals, introducing codesign to the next generation of computer science and computer engineering students remains something of an experiment. As they aptly observed, “different design cultures hamper integration,” and their own agenda is framed in terms of developing a more “appropriate curriculum” for computer science students. Yet the benefits of such reforms are increasingly clear. Serra and Gardner explained, for instance, that the interdisciplinary linking of computer science and engineering, as well as intradisciplinary explorations within computer science, were novel features and a “source of great strength” in their codesign course (p. 8). Emphasizing the extent to which hardware/software codesign challenges insular computer curricula, they added that “hardware related topics were tremendously empowering to the mainly software students in Comp. Science, who found the demistification [sic] of the whole area of VLSI design and CAD software useful to their breadth” (p. 8). Although these initial results are clearly encouraging, recent currents in the educational sphere reveal that proponents of the codesign movement may continue to

face formidable challenges, especially as they work to introduce these alternative design approaches into the curricula of computer science and engineering. In fact, the recent story of the Computing Curricula 2001 (CC2001) effort suggests that forces of fragmentation and segmentation have once again gained momentum. A joint venture of the IEEE Computer Society and the ACM, the CC2001 task force was charged with reviewing and updating the CC1991 report. Yet unlike the previous committee, the group quickly splintered out to develop separate reports with separate recommendations for four different disciplines, namely computer science, computer engineering, software engineering, and information systems. In an attempt to justify these divisions, the authors of the computer engineering volume argued that although efforts to merge the computing curricula “may have seemed reasonable in the past, there is no question that computing in the twenty-first century encompasses many vital disciplines with their own identities and pedagogical traditions” (Joint Task Force on Computer Engineering Curricula, 2004, p. 1). In light of the tensions that marked earlier eras of computing, one will likely read such passages with a sense of déjà vu. Further, the committee’s explicit emphasis on identity and pedagogy reveals that the persistent divides between computer engineering, computer science, and related fields is perhaps as much social as it is technical. And although these trends may pose challenges for the continued expansion of the codesign movement, my analysis suggests that the codesign movement itself may point the way toward a more integrated “discipline of computing,” both in educational contexts and beyond.

Conclusion: From Hardware/Software Codesign to Sociotechnical Codesign Although I have suggested that significant barriers must be overcome before codesign methods can move to the forefront of the computer field, it is worth closing with an even more ambitious vision for the future. As the preceding overview makes clear, hardware/ software codesign remains significantly technology oriented. However, I contend that the boundary-blurring characteristics of the codesign approach provide inspiration for another important line of reform. In their 1991 paper, codesign proponents Franke and Purvis cited a 1986 article in which well-known computer researcher Elliott Organick described the emergence of a new breed of “heterosystems” engineers. Skilled in working with large systems composed of “diverse, interacting components,” Organick explained that these



designers “are no longer just software engineers or just hardware engineers” (quoted in Franke & Purvis, 1991, p. 347). Franke and Purvis tentatively worked in similar directions when they noted that computer system professionals were increasingly involved in the design of “reactive” systems that involved hardware, software, and “users and objects from the real world” (p. 346). Some may notice parallels here with contemporary research in a variety of fields, including science and technology studies. As described by Donald MacKenzie (1990), for example, successfully developing new technologies often requires heterogeneous engineering, or “the engineering of the social as well as the physical world” (p. 28). Still others may recognize that terms such as codesign and metadesign have been used to describe new approaches to technological design that center on open and extensible systems and active efforts to blur the user-designer boundary.12 Hence, by challenging the drawing of a priori boundaries around hardware and software, codesign methods can inspire us to call into question other boundaries, such as those that divide computer scientists from engineers or those that separate computer technologies from users, applications, and even society. After all, the history of the software-hardware boundary forcefully reveals the extent to which the social and technical are deeply intertwined. It is hoped that ongoing moves to put back together the Humpty and Dumpty of software and hardware may also point us toward a more thoroughly contextualized, reflexive, and socially responsible culture of computing.

Notes 1. As further described by Jasanoff, scientific knowledge, as well as technology and technological knowledge, “both embeds and is embedded in social practices, identities, norms, conventions, discourses, and institutions—in short, in all the building blocks of what we term the social” (p. 3). 2. The historical summary developed here is significantly informed by early histories of ENIAC and closely related topics. See, for example, the accounts developed by Van der Spiegel, Tau, Ala’ilima, and Ang (2000) and Akera (1998). 3. Historian Jennifer Light (1999) has described, for example, how a small group of women were schooled in the art of programming and operating ENIAC. As Light made clear, these female programmers developed an in-depth knowledge of the machine and ingenious approaches to making it work. And although their contributions have been largely ignored or marginalized in the historical record, authors such as Light are redressing this oversight. 4. Yet for many years, transforming higher level problems into binary code, or the “unmediated language of the machine,” continued to require tedious detail work and a nuanced understanding of

a machine’s operational characteristics. This started to change, however, with the advent of higher level computer languages in the 1950s. 5. Mauchly more specifically explained that “reference has already been made to the uncertain status of division as a built-in operation. Many others, such as forming logarithm, cosine, arctangent, or square root, have been built into existing machines” (p. 205). As noted above, the intended application of a given machine was a key factor in deciding which of these more complex operations should be “built in.” If one were designing a highspeed computing device to calculate ballistics firing tables, for instance, it might be highly advantageous to include trigonometric functions in the machine’s instruction set. 6. This statement is also striking because it foreshadowed the later development of “software engineering” as a new subfield of computing. In fact, the term software engineering did not enter wide circulation until the late 1960s. 7. In fact, Hopper can be credited with developing the first compiler in 1952. In summary, compilers translate symbolic mathematical codes into the unmediated machine code required by a computer. This innovation was a major step forward, because computer programmers no longer had to write programs in binary code. This development also helped set the stage for the development of higher level programming languages. 8. The influence of Hopper’s remarks was further blunted by the fact that she was one of only a handful of women in the computing field. Through the early 1950s, it was clear that although women might make their way into computer programming, their contributions in the area of computer design were almost entirely limited to documenting existing work and in rare cases commenting on it. It is therefore not surprising that Hopper’s 1953 article was relegated to the upstart computer journal Computers and Automation. On the other hand, her article with coauthor Mauchly— who happened to be a member of IRE, unlike Hopper—was published in the more prestigious and technically oriented Transactions of the I.R.E. No matter the impressive the technical expertise accumulated by pioneers such as Hopper, the early field of computer design and engineering was all but impermeable to women, as well as to others without the appropriate credentials, experience, or identity. 9. In a 1961 Datamation editorial, author Herb Grosch (1961) worked in similar directions when he noted that “a few miles between software and hardware boys is healthy, but a hundred is too much” (p. 33). Although Grosch was explicitly referring to the increasing geographical distance between software and hardware experts, who were frequently segmented in different corporate divisions and even different companies, it also suggested a more general schism between the domains marked by the terms software and hardware. 10. VLSI involves the implementation of multiple functions and systems on a single microchip via integrated circuit technologies. The scale and complexity of these devices require specialized design tools and languages. An embedded system, on the other hand, is a special-purpose computing device designed for a specific application. Examples include the computers that are built into automobiles, household appliances, calculators, and so on. The limited functionality of these devices makes them particularly amenable to codesign methods. Scaling up the codesign approach so that it can be used to design more complex or general-purpose systems is an important challenge.


508 BULLETIN OF SCIENCE, TECHNOLOGY & SOCIETY / December 2006 11. Of course, other contextual factors were likely in play. For example, the availability of research funding for cutting-edge computer system design projects may have been on the rise around this time, especially in the midst of concerns about American competitiveness in the area of electronic and computer technology. 12. The work of Fischer (2002) on the topic of metadesign provides significant inspiration here. And although Fischer’s efforts are largely focused on software development, many of his ideas and approaches would likely prove compatible with the design of integrated hardware and software systems.

References ACM Curriculum Committee on Computer Science. (1968). Curriculum 68: Recommendations for the undergraduate program in computer science. Communications of the ACM, 11(3), 151-197. Akera, A. (1998). Calculating a natural world: Scientists, engineers, and computers in the United States, 1937-1968. Unpublished doctoral dissertation, University of Pennsylvania. Burroughs Corporation. (1962). When . . . ? [advertisement]. Datamation, 8(8), 14-15. Carr, J. W., III. (1956). Conference summary. In Proceedings of the Eastern Joint Computer Conference, New York, NY, December 12, 1956 (pp. 147-150). New York: American Institute of Electrical Engineers. Carr, J. W., III. (1962). Better computers. Elektronische Rechenanlagen, 4(4), 157-160. Carr, J. W., III. (1965). The future of programming and programmers. Computers and Automation, 14(1), 15-17, 54. Coates, C. L., Jr., Arden, B., Bartee, T. C., Bell, C. G., Kuo, F. F., McCluskey, E. J., Jr., et al. (1971). An undergraduate computer engineering option for electrical engineering. Proceedings of the IEEE, 59(6), 854-860. COSINE Committee, Commission on Engineering Education. (1967, September). Computer sciences in electrical engineering. Washington, DC: COSINE Committee. COSINE Committee, Commission on Engineering Education. (1968). Computer science in electrical engineering. IEEE Spectrum, 5(3), 96-103. COSINE Committee, Commission on Engineering Education. (1970, January). An undergraduate computer engineering option for electrical engineering. Washington, DC: COSINE Committee. A Datamation staff survey of computer components ’61. (1961, August). Datamation, 7(8), 36-40. Denning, P. J., Comer, D., Gries, D., Mulder, M. C., Tucker, A. B., Turner, A. J., et al. (1989). Computing as a discipline. Communications of the ACM, 32(1), 9-23. Ernst, R., & Borriello, G. (1997). Message from the workshop chairs. In Proceedings of the 5th International Workshop on Hardware/Software Co-Design, 1997 (CODES/CASHE ’97), March 24-26, 1997 (p. viii). Washington, DC: IEEE Computer Society. Fischer, G. (2002). Beyond “couch potatoes”: From consumers to designers and active contributors. First Monday, 7(12). Retrieved January 10, 2006, from http://www.firstmonday.dk/ issues/issue7_12/fischer/index.html Franke, D. W., & Purvis, M. K. (1991). Hardware/software codesign: A perspective. In Proceedings of the 13th International

Conference on Software Engineering, Austin, TX. Los Alamitos, CA: IEEE Computer Society Press. Gieryn, T. F. (1983). Boundary work and the demarcation of science from non-science: Strains and interests in professional ideologies of scientists. American Sociological Review, 48, 781-795. Gieryn, T. F. (1995). Boundaries of science. In S. Jasanoff, G. E. Markle, J. C. Petersen, & T. Pinch (Eds.), Handbook of science and technology studies (Rev. ed., pp. 393-443). Thousand Oaks, CA: Sage. Gieryn, T. F. (1999). Cultural boundaries of science: Credibility on the line. Chicago: University of Chicago Press. Golinski, J. (1998). Making natural knowledge: Constructivism and the history of science. Cambridge, UK: Cambridge University Press. Gorn, S. (1958). Letters to the editor. Communications of the ACM, 1(1), 2-4. Gorn, S. (1959, September). On the logical design of formal mixed languages. In Preprints of papers presented at the 14th National Meeting of the Association for Computing Machinery (p. 25-1). New York: Association for Computing Machinery Press. Grosch, H. R. J. (1961). Software in sickness and health. Datamation, 7(7), 32-33. Hopper, G. M. (1953). Compiling routines. Computers and Automation, 2(4), 1-5. Hopper, G. M., & Mauchly, J. W. (1953). Influence of programming techniques on the design of computers. Proceedings of the I.R.E., 41(10), 1250-1254. Householder, A. S. (1956). Presidential address to the ACM, Philadelphia, September 14, 1955. Journal of the ACM, 3(1), 1-2. Institute of Radio Engineers Professional Group on Electronic Computers. (1952). Foreword. Transactions of the I.R.E. Professional Group on Electronic Computers, 1(1), 1. Institute of Radio Engineers Professional Group on Electronic Computers. (1953). Editorial. Transactions of the I.R.E. Professional Group on Electronic Computers, 2(1), 1. Irwin, D. J., & Ramamoorthy, C. V. (1975). Guest editor’s introduction. Computer, 8(12), 26-27. Jasanoff, S. (Ed.). (2004). States of knowledge: The co-production of science and social order. London: Routledge. Joint Task Force on Computer Engineering Curricula. (2004, December). Computer curricula: Computer engineering (final report). Retrieved February 10, 2005, from http://www.eng .auburn.edu/ece/CCCE/CCCE-FinalReport-2004Dec12.pdf Light, J. S. (1999). When computers were women. Technology and Culture, 40(3), 455-483. MacKenzie, D. (1990). Inventing accuracy: A historical sociology of nuclear missile guidance. Cambridge, MA: MIT Press. MacWilliams, W. H., Jr. (1951). Keynote address. In Review of Electronic Digital Computers: Joint AIEE-IRE Computer Conference, Philadelphia, PA, December 10-12, 1951 (pp. 5-6). New York: American Institute of Electrical Engineers. Mauchly, J. W. (1948). Preparation of problems for EDVAC-type machines. In Proceedings of a symposium on large-scale digital calculating machinery, Cambridge, MA, January 7-10, 1947 (pp. 203-207). Cambridge, MA: Harvard University Press. Mesa Scientific Corporation. (1964). Mesa men [advertisement]. Datamation, 10(11), 45. Mulder, M. C. (1975, December). Model curricula for four-year computer science and engineering programs: Bridging the tar pit. Computer, 8(12), 28-33.


Jesiek / BOUNDARIES OF HARDWARE AND SOFTWARE 509 Rose, C. W., & Albarran, M. (1975). Modeling and design description of hierarchical hardware/software systems. In Proceedings of the 12th Conference on Design Automation (pp. 421-430). Piscataway, NJ: IEEE Press. Serra, M., & Gardner, W. B. (1998). A first course in hardware/software codesign. In Third Western Canadian Conference on Computing Education (WCCCE ’98), Vancouver, BC, May 1998 (pp. 57-66). Retrieved May 6, 2004, from http://www.uoguelph .ca/~gardnerw/pubs/WCCCE98.pdf Shapiro, F. R. (2000). Origin of the term software: Evidence from the JSTOR electronic journal archive. IEEE Annals of the History of Computing, 22(2), 69. Should we merge with the ACM and leave the IEEE? An interview with Dr. Albert S. Hoagland, president of the IEEE Computer Society. (1972, May/June). Computer, 5(3), 1. Tanenbaum, A. S. (1976). Structured computer organization. Englewood Cliffs, NJ: Prentice Hall. Tucker, A. B. (Ed.). (1990). Computing Curricula 1991: Report of the ACM/IEEE-CS Joint Curriculum Task Force. Pasadena, CA: IEEE Computer Society Press.

Van der Spiegel, J., Tau, J. F., Ala’ilima, T. F., & Ang, L. P. (2000). The ENIAC: History, operation, and reconstruction in VLSI. In R. Rojas & U. Hashagen (Eds.), The first computers: History and architecture (pp. 69-87). Cambridge, MA: MIT Press. Williams, S. B. (1954). The Association for Computing Machinery. Journal of the Association for Computing Machinery, 1(1), 1-3.

Brent K. Jesiek received his BS in electrical engineering from Michigan Tech in 1998, and he entered the science and technology studies program at Virginia Tech in 2001. He received his MS in 2003, and he is now a PhD candidate. In addition to serving as manager of Virginia Tech's Center for Digital Discourse and Culture (CDDC), he teaches in science and technology studies. His research interests include hardware and software design methods, instructional technology, and the history of computer engineering.


Bulletin of Science, Technology & Society

Bulletin of Science, Technology & Society

Suggest Documents