According to Borsook, the technolibertarian ideology of high tech pervades Silicon Valley, and indeed, Takhteyev might argue, the global “world of practice” of programmers everywhere. Yet here I return to a question I posed earlier—what is the role of Cocoa
technology itself? For Cocoa developers, it not only matters that they have “access to tools,”
but also what those tools are—Cocoa itself. To them, the properties of Cocoa and the practices associated with using it make a difference, both on an affective basis, in which they claim it is more enjoyable to work with than other development tools, as well as on a rational or utilitarian basis, in which they claim it is technically superior to other tools.
The basis for this claim lies in Cocoa’s object-oriented nature. Object-oriented programming is a methodology for programming and programming language design that emerged in the late 1960s and early 1970s. Unlike traditional procedural programming, in which a programmer envisions a program as a set of processes and procedures through which program execution flows, in object-oriented programming a program is envisioned as a configuration of black-boxed objects, which have often hierarchical relations to each other, and cause things to happen by sending messages to each other. The term was coined by Alan
36
Kay at Xerox PARC to describe his Smalltalk programming language and user environment, and although Smalltalk was not the first object-oriented language,13 concepts it pioneered have been exceedingly influential in the development of later languages, such as Java, Python, Ruby, as well as C, the language at the heart of Cocoa. In fact, Objective-C was originally developed to add a simple Smalltalk-like layer on top of the industry-leading C programming language, which is not object-oriented. Steve Job’s NeXT chose Objective-C to be the foundation for its operating system’s software libraries, which later developed into Cocoa at Apple.
That a technology originating at Xerox PARC became the centerpiece of yet another of Jobs’ ventures is no accident. In an interview for the PBS documentary, “Triumph of the Nerds,” Jobs acknowledged that he had seen both object-oriented programming and
networking at PARC during his famous visit in the late 1970s, but had failed to see its importance at the time: “One of the things they [PARC] showed me was object orienting [sic] programming… The other one they showed me was a networked computer system...
[but] I didn’t even see that… I was so blinded by the first thing they showed me which was the graphical user interface.” (Cringely 1996b)14 Jobs had not realized that PARC’s
Smalltalk System was an integrated whole—its graphical user interface was built with object-oriented libraries and techniques, and the entire system, not just the programming language or the user interface, was what Smalltalk was. Jobs had only grasped the
technology at the superficial level, and at Apple, his engineers replicated the look and feel of the graphical user interface on the Lisa and Macintosh but did it with radically different, non-object-oriented technologies. This was largely a necessity, however, as the Macintosh was supposed to be a mass-market consumer device, its hardware was considerably less
13 Joline Zepcevski argues that Simula-67 was the first language to contain the necessary features to today be classified as “object-oriented.” (Zepcevski 2012, 226–227)
14 Michael Hiltzik’s book on Xerox PARC says much the same thing: “As for Jobs, he was so ‘saturated’ by the power of the user interface he had seen that he ignored the other two phenomena he was being shown: object-oriented programming, which was the essence of Smalltalk, and networking.” (Hiltzik 1999, 343)
37
powerful than the Alto’s (originally shipping with only 128K of memory) and Smalltalk’s object-oriented environment was resource intensive and inefficient and would not have run on the original Mac. This strategy worked successfully in the short run to ship the Mac, but the limitations of the Mac’s programming environment, the Macintosh Toolbox, would come to haunt Apple in the 1990s as it tried to modernize its operating system. After Jobs left Apple to form NeXT, he hired top computer science researchers such as Avie Tevanian from Carnegie Mellon. By the late 1980s, object-oriented programming had become the next big thing in computer science, with its own conferences, and NeXT made it a centerpiece of its new platform. In a way, Jobs may have been trying to recreate a PARC-like environment at NeXT, by hiring, in his opinion, the best and brightest and let them decide what
technologies should go into a bleeding edge computer. NeXT’s focus on networking, which it marketed as the new paradigm of “interpersonal computing,” was really a take on Xerox’s
“personal distributed computing.” (Lampson 1986; Thacker 1986) Similarly, NeXT’s graphical user interface was built using object-oriented libraries, just as Smalltalk was, and it was written with a language, Objective-C, that was explicitly modeled after Smalltalk.
Why is object-oriented programming, and Smalltalk-based technology in particular, so important to Cocoa programmers? To answer this question, we must look at the context in which object-oriented programming came about, during the so-called “software crisis” of the 1960s,15 alongside the emergence of “software engineering.” As we will see in chapters 2, 3, and 6, Cocoa developers claim that because Cocoa is object-oriented, it can improve programmer productivity by an order of magnitude, through reducing complexity and
15 Thomas Haigh argues that the software crisis was in reality more a discursive construction by Dijkstra to overstate crisis language in the 1968 NATO Conference
proceedings during his 1972 Turing Award acceptance speech. Dijkstra did this to criticize the “failure of computer companies to recognize the mathematical nature of software
development and their insistence on hiring insufficiently intelligent people to do it.” (Haigh 2010) Talk of the crisis is later seized upon by historians of computing in connection with software engineering, but Haigh argues that this is overblown with regard to the concerns of actual software practitioners.
38
increasing the maintainability of programs. Historian Michael Mahoney understood object-oriented programming to be a particular response to the software crisis. “One only has to read Doug McIlroy’s ‘On Mass-Produced Software Components,’ presented to the first NATO Software Engineering Conference in 1968, to see where the conceptual roots of object-oriented programming lie.” (Mahoney 1993, 778) A recent dissertation by Joline Zepcevski argues that both structured programming and object-oriented programming methodologies developed concurrently in the 1970s to tackle the software crisis, Smalltalk especially. Both of these methodologies sought to address the issues of the complexity of software, and its successful verification. Both approaches encouraged increasing
modularization and reuse of code, and while these principles were previously voluntary practices to be encouraged, new languages designed specifically to support the new
methodologies (such as Pascal and Ada for structured programming, Smalltalk and C++ for object-oriented programming) began to enforce them more rigidly. Nevertheless, Zepcevski argues that only object-oriented programming represented a change in worldview from the earlier procedural programming paradigm: instead of viewing a program as a flow of processes, it transforms programs into systems of dynamically interacting, communicating objects (Zepcevski 2012).
Zepcevski’s work draws on a growing literature on the software crisis and software engineering in the history of computing. (Abbate 2012; Ensmenger 2010; Ensmenger and Aspray 2002; MacKenzie 2001; Mahoney 1990; Mahoney 2002; Mahoney 2004; Slayton 2013a) In the late 1960s, the computer industry began to note that software development costs were outpacing hardware costs, there seemed to be a perennial shortage of skilled programmers, and several large, highly complex software projects failed spectacularly, including OS/360, IBM’s operating system for its next generation System/360 series of computers. What she identifies as the problem of managing overwhelming complexity in programming was a central concern for figures influential in the development of software engineering, especially Fred Brooks, the IBM software manager who oversaw OS/360 and wrote the influential The Mythical Man-Month (F. P. Brooks 1995) as a post-mortem of the project, which became a canonical text in software engineering. Brooks wrote in 1987 that complexity was one of the “essential” traits of programming that meant that no technology
39
or technique, “No Silver Bullet,” could ultimately solve the software crisis. (F. P. Brooks 1987)
Brad Cox, the creator of the Objective-C programming language, disagreed. Cox claimed that object-oriented programming (combined with a market of off-the-shelf software object components that programmers could buy) was not only a silver bullet, but would usher in a “software industrial revolution,” taking programming out of the realm of craft and into the era of manufacturing (Cox 1990b; Cox 1990a). Historian Michael Mahoney has pointed out how the dream of “automatic programming” and the “software factory” has a long history, which became especially pronounced with the software crisis (Mahoney 2002). Nathan Ensmenger has cited Brad Cox as an example of the emphasis in software engineering towards the development of technologies and methodologies to aid in the management of unruly programmers, as programmer unmanageability was one of the key perceived sources of the software crisis (Ensmenger and Aspray 2002, 15–16). Indeed, the metaphor of “engineering” itself, chosen in part to give programming an air of
quantification, rigor, discipline, professionalization, masculinization, and thus status, lent itself easily to discourse involving the industrial revolution, manufacturing, interchangeable parts, and automation. Sociologist Phillip Kraft warned in the 1970s that many of the
techniques proposed by software engineering advocates, such as structured programming, a set of formalized, disciplinary programming practices advocated by computer scientist Edsgar Dijkstra, would increasingly routinize and deskill programmers (Ensmenger 2010, 231–2). Ensmenger, examining the managerial rhetoric of such efforts, largely agrees that control over labor was a primary motivation of software engineering, and that in corporate settings, managers did indeed increase a measure of control, but feels that ultimately, the rhetoric was overblown, as programming continues to require craft skill (Ensmenger 2010, 47–49, 243). For Ensmenger, programming simply proved intractable to managerial
attempts to discipline it.
Donald Mackenzie and Janet Abbate, however, interpret the discourse of software engineering differently. Both note that “Software engineering advocates such as Dijkstra and Brooks identified as programmers themselves and had no desire to downgrade their peers.” (Abbate 2012, 107) Mackenzie points out that “Dijkstra recoiled at the analogy of
40
the factory. When asked his profession, he was proud to declare himself simply a
‘programmer’: for him, programming was intrinsically a demanding activity… The discipline needed for successful programming was not organizational and managerial, in Dijkstra’s opinion, but intellectual.” (MacKenzie 2001, 40) Mackenzie further notes that Harlan Mills’ adoption of structured programming at IBM resulted in the opposite of deskilling: “The tasks that programmers were left with, however, after the discipline of structured programming had been imposed, were far from routine. Mills’s [sic] cleanroom demanded more, not less, from its programmers…” (MacKenzie 2001, 57) Similarly, Abbate states, “Unlike most industrial or office automation, software innovations were created and adopted by programmers themselves, not managers… Rather than a serious goal, deskilling functioned more as a handy cultural trope that marketers could use to appeal to potential customers.” (Abbate 2012, 85) “Many programmers actively took up techniques such as structured programming as a way of easing their work and enhancing their own value in the job market. Rather than making programmers obsolete, software engineering methods became simply another skill that programmers could claim.” (Abbate 2012, 107–
108) As we will see in chapter 3, my own interviews with Cocoa programmers, who have embraced a cultural-technological frame that deeply embeds many software engineering principles, corroborates Abbate’s argument. Software engineering techniques, despite deskilling or routinizing rhetoric, discipline the programmer in the name of building professional skill more than managerial docility. Both structured programming and object-oriented programming methods are standard curricula in computer science, part of the trade knowledge of the profession, and have increased, rather than decreased, the skill involved in programming. Experienced programmers today largely see the acceptance of these
methodologies as evidence of progress in the field, not as the triumph of managerial interests.
Why have such methods been so widely accepted in programming? Another essential characteristic of software that made it difficult to write, Brooks asserted in “No Silver Bullet,” was its changeability, in order to respond to new feature requests from users, and new hardware that it must support. This need to change is rooted in software’s inseparability from its larger social context: “In short, the software product is embedded in a cultural
41
matrix of applications, users, laws, and machine vehicles [hardware]. These all change continually, and their changes inexorably force change upon the software product.” (F. P.
Brooks 1987, 12) Although software is more easily changed than hardware, in practice it is not “infinitely malleable” as Brooks would have it. It is in fact because, as Nathan
Ensmenger puts it, “Software is history, organization, and social relationships make
tangible,” (Ensmenger 2010, 227) that software is obdurate, constrained by design decisions made in the social, institutional, and material context in which it was first written. Because of the long lifecycles of many programs, choices made today that limit future flexibility and malleability in the name of expedience or efficiency have deleterious effects decades into the future. It was this problem of “legacy software” that caused the panic over the Y2K bug:
the COBOL programs that ran much of the nation’s financial infrastructure had been written in the 1960s, when it was necessary to save memory by omitting the first two digits of a year, but these programs’ lifecycles lasted into the 1990s and past the year 2000, requiring expensive rewriting of all of this stable, working, infrastructural code. Ensmenger calls this the problem of software maintenance, and argues that “the software crisis of the late 1960s was essentially a maintenance problem.” (Ensmenger 2010, 224–225) Although
maintenance is low-status and boring, as programmers would rather be makers of the new rather than repairers of the old, because even new programs take a long time to write while goals are constantly changing, the line between creation and repair can become blurry in software, as bug fixing is always the final step towards releasing a “new” software product.
And as we will see in chapter 6, experienced software developers argue that adopting
disciplined practices up front to make software more “maintainable” will not only pay off in the long run, but is seen as taking a step towards increasing one’s professional skill and standing in the community of practice. This, in turn, can make the difference between being accepted or excluded as a member of the professional community. Such “best practices” can exist independently of particular technologies, but sometimes are strongly associated with particular programming languages, development environments, and conventional coding idioms. Such is the case with certain software design practices and Cocoa technology.
Cocoa programmers assert that the reason Cocoa is a superior tool for writing software is because of Cocoa’s dynamic and flexible object-oriented design, and the conventional practices and idioms associated with its use, which they claim help make their software
42
more maintainable. Practices that emphasize the virtue of maintainability are part and parcel of the techno-cultural frame associated with Cocoa programming.
Methodology
I came to science and technology studies out of a program in history, and I began my studies with a much stronger sense of the disciplinary ways of thinking of historians.
However, when I began this project, being in science and technology studies allowed me to ask contemporary questions and to study contemporary phenomena. I intended for the project to be equal parts historical and equal parts contemporary. I attempted to find sources on NeXT at the Charles Babbage Institute and Stanford Library’s Special Collections, but beyond a few NeXT brochures in the Michael Mahoney papers and a draft of a proposed paper to the third History of Programming Languages conference on Objective-C, and a cache of NeXTWORLD magazines that I later also found online, I found little of direct relevance to my dissertation, although I did find a lot of materials on object-oriented programming. I did eventually find a few sources to conduct oral histories of NeXT
developers and a few NeXT employees. (I will discuss my interview methods below.) Given only a handful (less than ten) oral history interviews pertaining to NeXT, and the dearth of written sources, I felt that I could not accomplish a sufficiently robust history of NeXT or the NeXT developer community in the current project, other than the rough outline given in chapter 2, which is drawn largely from the NeXTWORLD magazines, the NeXT brochure, and excerpts from my interviews. I thus decided to focus more on the contemporary
ethnographic and interview-based portion of the project. The result is that I see this work as more a work of sociology of technology with ethnographic and historical components.
Chapter 2 is the most historical chapter, being based as much on documents (magazine articles and marketing materials from the 1990s) as on oral history interviews, and is closest to telling a chronological narrative, for the purposes of providing necessary historical
context for the rest of the dissertation. Other chapters, especially chapter 6, draw on secondary historical literature as well as on interviews. Despite my extensive use of
historical (both primary and secondary) sources, this dissertation is not primarily a work of history. It does not directly address many questions of central concern to historians of computing and software raised by Michael Mahoney, such as the social or institutional
43
context of hardware or software, communities of computer users in the professions, or the history of software engineering or computer science as a discipline or programming as a profession (Mahoney 1993, 779–80). Rather, I have used my oral histories to provide context on the life and career trajectories of my participants. Nevertheless, this dissertation does touch on some themes outlined by Mahoney: it documents the practice of a specific community of programmers, in particular, the tacit knowledge, the tricks of the trade, the
“body of techniques, and the habits of thought” of Cocoa programmers (Mahoney 1993, 774). It does this by opening the black box of Cocoa software, by reading the software artifact that is Cocoa, through engagement in the practice of Cocoa programming itself.
Moreover, Mahoney argues that all software is legacy software, which bears the traces of its history.16 On one level, the development of Cocoa and Objective-C, and associated
disciplinary practices, were an attempt to address the problem of maintenance of legacy software, to improve its reliability and flexibility. On another level, Cocoa itself is legacy, in the sense that its design bears the mark of its origins at NeXT and its passage through a period where it was applied primarily to the problems of large enterprises and institutions, not consumers with smartphones. Cocoa must also be understood in the ideological context of the computer counterculture and utopian digital technolibertarianism.
This dissertation draws primarily on semi-structured interviews and ethnographic participant observation. As I had been an Apple employee myself till 2005, I began recruiting participants for my project through my network of social contacts that I had formed at Apple. After being turned down for permission to interview Apple employees (and thus my former coworkers still working at Apple) by vice presidents Scott Forstall and Bertrand Serlet because of Apple’s secrecy policies, I refocused my project on third party developers who did not work for Apple. My network of contacts at Apple, and my own
This dissertation draws primarily on semi-structured interviews and ethnographic participant observation. As I had been an Apple employee myself till 2005, I began recruiting participants for my project through my network of social contacts that I had formed at Apple. After being turned down for permission to interview Apple employees (and thus my former coworkers still working at Apple) by vice presidents Scott Forstall and Bertrand Serlet because of Apple’s secrecy policies, I refocused my project on third party developers who did not work for Apple. My network of contacts at Apple, and my own