Writing high-level, object-oriented code also has an additional benefit. It allows a programmer to use less code to express the same amount of functionality—
in fact, often an order of magnitude less code. Calling certain Cocoa APIs often allow a programmer to trigger complex events with only a single line of code. As we
167
saw in Wil Shipley’s earlier quote, compared to a programmer who writes
completely in C, “I wrote it in Objective-C and it’s six times shorter.” (Wil Shipley April 18, 2012) Thus, a key reason using Cocoa makes a programmer an order of magnitude more productive is because she needs to do an order of magnitude less work for the same result. We also saw earlier that Brent Simmons equated this with power: “The ability to do more with less code.” (Brent Simmons Interview, February 17, 2012)
Being able to “do more with less code” magnifies the capabilities of individual programmers, but at the same time, reduces the need for large teams to produce the same level of functionality. In this way, Cocoa levels the playing field for individual developers against large corporate software firms. The productivity benefits from being able to “do more with less code” makes the “indie” developer possible—it allows developers to retreat from corporately managed software
organizations. For this reason, “less code” has become something of a virtue within the Cocoa community.
Within the Cocoa community, “more code” is a vice associated with corporate software practices that are the result of perverse incentives counterproductive to producing good programs. Developers sometimes spoke of older corporate
compensation policies that paid by lines of code written, equating quantity of code with functionality produced. For Cocoa developers, however, more code does not mean better quality—it adds complexity, increasing the probability for errors, and thus decreasing software’s maintainability over time. Cocoa developers feel that the perverse incentive to generate more code has contributed to the intractability of large, complex, buggy legacy software systems that programmers are afraid to touch for fear of breaking them. Developer Wil Shipley felt that the corporate software industry simply did not understand that less code translated directly to higher programmer productivity.
The preponderance of evidence is, we’ve got all these [Cocoa]
programmers who are making these programs in record time that don’t seem very buggy and seem very performant… we’ve got all these
168
things that we’ve made with tiny teams that are beautiful and they’re using Cocoa and I think we’ve proven that having less code in an app is just better…
As late as the ‘90’s people were still saying… I want a language that lets me [run programs] really fast, I want a language that lets me get to the hardware—the goal wasn’t see how little code you can write. And I think it’s only in the last ten years that we started understanding… the only method that really matters is less code.
It’s very rare, it’s the exception, do you say, ‘Oh, no, this is too slow, so I’m going to make it a little more code,’ but that’s an exception.
The only method that matters is how little code did you use, overall.
That’s the only thing. There’s no other metric, because they all fall out of that. Is it fast? Well, generally less code is going to be faster. Not always, but generally. And also, if you use less code, you’re [more likely to be] reusing things and you can optimize things that you’re reusing and someday you’ll think it’s faster and magical, right? It falls out. (Wil Shipley, Interview, April 18, 2012)
Becky Willrich, a former software engineer on the Cocoa team, explained how, at Apple, Mac OS X’s designers created two levels of APIs: Cocoa was the high-level, object-oriented Objective-C layer, which was built on top of a low-level, procedural, C-based layer. According to Willrich, Apple’s engineers tried to make the Cocoa APIs as simple and convenient as possible, for the vast majority of the interface’s users (who are programmers). However, if they needed access to functionality that the Cocoa APIs did not provide, they could drop down to the lower-level C layer, with access to the complete toolchest. This, however, meant having to manage considerably more complexity that the Cocoa APIs hid from the user, a complexity Willrich called “cognitive load.”
“Most developers may want to do this—what if they want to configure just one [thing]… Why don’t we just add [this one option]? Well no.
That adds to the cognitive load of the simple API. Right? Because now you have to learn a little more. …It was just a very high bar for adding essentially, developer convenience… Because any time you added developer convenience to these simple APIs, they become less simple…
And then you provide them will a full toolkit, a full tool chest, if they want to look under the hood, it’s all there, they can tinker with
whatever they want, but now it’s their responsibility…Once you reach
169
that low level, you really have to… trust that the developer knows what they’re doing…” (Becky Willrich Interview, April 15, 2012) Willrich saw that precluding options in the high-level API was justifiable because if the programmer really needed those options, they could go to the lower-level API. This would keep the high-lower-level API simple, to maximize simplicity and thus ease of use for the largest number of programming users. The unlucky few would have to take the extra time to learn the low-level API instead, but because they were few in number, this was a valid tradeoff:
If we have satisfied 95+ percent of the developers we do not mind that the remaining three, four or five percent are going to have to work a lot harder. It is worth giving the 95% a simple one-line API at the expense of requiring substantial work on the part of this, three, four, five. Because… if you look at those 5% of developers for whom the simple API is not complex enough, [for] at least half of them, no API would have been sufficient shy of the full toolkit. …You’re going to end up wanting all the bells, knobs and whistles anyway. So it’s not like I could have provided a slightly more complex but still basically simple API and still satisfied you. So they don’t count anymore. They were satisfied when I exposed the full toolkit, OK? So now you’re only talking about 2% or so of people who might have genuinely been helped by a slightly more complex but still simple API. And the cost of telling them, “look, we’re sorry but you’re going to have to become at least passingly familiar with this bigger, fuller toolkit,” that’s fine. I have no problem with that. [Rather than burden the rest of the 95%]
with even a slightly higher cognitive load…
(Becky Willrich, Interview, April 15, 2012)
Thus, Apple’s designs for Cocoa emphasize giving developers convenience functions to allow them to do common things simply and easily, with as little code as possible. Simultaneously, it also provides more specialized capabilities that would take developers hundreds of lines of code to implement for themselves, a task that likely would require collaboration with additional programmers to accomplish.
Developers noted that Cocoa gave them capabilities they wouldn’t have had otherwise:
As somebody who is a creative person… tools like [the]
CoreAnimation [framework] make it extremely easy to do things that
170
on Windows, I would be like, I don’t even know how to begin doing this. That’s just an example of… just great APIs.
(Adam Preble, Interview, August 8, 2011)
Prior to 2006, fancy animation effects had to be made using lower level, C-based graphics APIs such as OpenGL, taking a lot of extra work. In 2006, Apple introduced CoreAnimation, a framework exposing a set of Objective-C APIs that made doing animations relatively simple. CoreAnimation was layered on top of OpenGL, and provided a simple, abstract interface for developers that still allowed animations to be hardware accelerated. This is a good example of the kind of two-tiered API design Willrich discussed. Advanced programmers, who want
significantly more options, control, and performance, will still want to use OpenGL, especially for games. However, for the kinds of simple, elegant, and common
animations in the user interface, such as the smooth swiping effect that a user sees on an iPhone, CoreAnimation provides, in a few lines of code, what would take
hundreds of lines to accomplish in the OpenGL APIs.
Cocoa code libraries such as CoreAnimation encapsulate complex
functionality in simple interfaces. With only a few simple calls to these interfaces, a Cocoa programmer can implement what would take programmers using less
functionally rich libraries hundreds or thousands of lines more code. In essence, by building more and more functionality into the high-level Cocoa libraries, Apple removes the need for developers to write such functionality themselves, using the low-level interfaces.
There is a division of labor implied in this. Remember Fred Brooks and Harlan Mills’ chief programmer or “super-programmer” model of organizing software work, which Brooks discussed in The Mythical Man Month (F. P. Brooks 1995). Instead of throwing armies of programmers at a project, and understanding the vast skill difference between the best programmers and average ones, in Brooks’
model, the chief programmer was responsible for the architecture and design, the big picture, while the lesser skilled staff merely implemented the components, conceived of as a more routinized job. The chief programmer, the architect, is thus “freed” from
171
the drudgery of routine programming tasks that need to be repeated. Brad Cox, creator of Objective-C, advocated a different division of labor. Object-oriented
programming, in Cox’s view, encouraged code reuse. Routine code could, and should, be encapsulated in objects and reused, reducing the need for such work to be
performed repeatedly in the future. This was key to how object-oriented
programming would improve productivity. The other piece of the puzzle was that such routinized labor could be outsourced not to one’s team of subordinates, but to the market. Cox thought that software objects should be bought and sold “off the shelf.” While some NeXT developers did indeed sell objects for other programmers to buy, this never really caught on, partly because there was a wide range in the quality of “objectware” in the market, and partly because such objects sometimes came with restrictive licensing agreements (Garfinkel 1993a; Garfinkel 1993b). It was not clear to programmers whether they should trust the objects that they bought from others.
NeXT, and subsequently Apple, offered a slightly different division of labor.
Like Cox’s solution, and using the language he created, in NeXT’s model, routine code would also be encapsulated in reusable objects. In a way, they would also be purchased in the market. But rather than acquire them piecemeal from heterogeneous sources, NeXT bundled entire libraries of objects along with the operating system and development environment, and earlier in its lifetime, with the computer hardware as well. These objects thus were built into the system that the user received, and were part and parcel of that system; the system itself was built using these objects. The issue of trust is much ameliorated, because the customer was already buying NeXT’s system, and thus was already putting a degree of trust in NeXT by doing so. And largely, NeXT, and later Apple, kept this trust. Because all of the objects were designed to fit together in a coherent, consistent system, with built-in support by all of NeXT’s developer tools, in particular, Interface Builder, and these objects were used by NeXT itself to make its own applications, developers could trust that these were world-class libraries, because the system itself was built on it.
172
The division of labor promised by Cocoa is thus, from the point of view of the Cocoa developer, a democratizing one, but not a deskilling one. “Routine” tasks are automated by the Cocoa libraries, leaving to developers the creative, intellective work of solving their users’ problems with their applications, work that cannot be automated. Says a former NeXT and Apple engineer, “There’s just this beauty in mechanizing these things that don’t need to be the programmer’s job.” (Julie Zelinski April 24, 2012) Routinized work is thus delegated to Apple, reducing the amount of manpower necessary for programming. The result is that small teams, or even a single programmer, can write highly complex applications, which would require masses of routinized, less-skilled programmers in traditional corporate organizations.
Because of the empowering effects of Cocoa, all Cocoa programmers are freed to do creative, rather than routine, work—in essence, everyone can be a
“super-programmer.” And because it allows individuals or small groups to be as productive as corporate armies, Cocoa also has the potential to make all programmers “indies.”
This is not to imply that the work of the Apple engineers in creating the Cocoa libraries themselves is actually routine and unskilled. In fact, it is highly skilled, perhaps more so than application programming using Cocoa. As the variance in quality of the third party NeXT objectware market showed, writing objects to be reused by others is not an easy task, as a programmer may not anticipate all the ways that object will be used. Indeed, as Steve Naroff indicated in my interview with him, Steve Jobs did not buy Brad Cox’s object libraries because he felt that Cox’s
employees were not “world class” but the engineers Jobs had hired at NeXT were. “I also knew that the people working on it at Stepstone were not world-class; I knew that it would be really hard for world class companies like NeXT to buy into
someone else’s ICPaks.” (Steve Naroff, Interview, December 22, 2012) As Willrich mentioned, a lot of care at Apple went into designing object interfaces that were as simple as possible for the largest number of users. This involved some guessing, but with “world class” engineers, more often than not, they guessed correctly. When they didn’t, this could be corrected in subsequent releases by changing the API, but this was not to be done lightly, as such changes could make earlier software incompatible.
173
Moreover, designing the libraries to be consistent throughout took a significant amount of vision, intentionality, coordination, and the control of key managers in NeXT’s, and later Apple’s, software team. This meant that the work of crafting an object library to be reused long into the future, and anticipating all the use cases correctly so that the library would not have to change significantly over time, takes a lot of knowledge and experience in good object-oriented design, which is anything but routine work. A bad job can result in software that does not match most users’
needs, or does not adapt to changing circumstances, thus needing to be thrown out and rewritten in only a few years. However, the AppKit’s core architecture has remained largely unchanged for over twenty years, and decisions made in the late 1980s and early 1990s have “stood the test of time.” Blaine Garst, a retired NeXT and Apple engineer, noted:
“It’s fascinating… looking back on design decisions you made 20 years ago, 18 years ago, 15 years ago that are still in play…
And you look at the technologies and the deployment environments and all these other environmental things that change around it, and you say, well, good core architecture can go a long ways. And that’s
effectively what we did. We took the existing AppKit, we reworked it… and made a good foundation for a lot of other things.
…Those names were still there last time I looked. You know? Stuff I did twenty years ago. So the naming conventions are still in place…
[Those decisions] have stood the test of some time.
(Blaine Garst April 13, 2012)
Another way that Apple makes it possible to write less code is that, using Interface Builder, it is sometimes possible to accomplish functionality without writing code at all. Over the years, Interface Builder has increasingly built in more ways to construct user interface components by manipulating them graphically using the mouse, and toggling a few options. The same thing can almost always be done
“programmatically,” by writing code, but this can often take substantial work, compared to the mere minutes involved in dragging a user interface object from a palette and configuring its options and connections. This convenience involves certain trade-offs, however. Not everything that can be done with the user interface
174
object is exposed in Interface Builder. A programmer may want to customize the way a button draws itself, for example. For these cases, a programmer has to write code;
writing the code not only gives the programmer a lot more power and control, it also helps the programmer understand in a lot more depth what the AppKit framework is doing behind the scenes.
More recently, for iOS development, Apple has introduced a feature in Interface Builder that allows a developer to graphically design not just a single screen of a user interface, but to graphically lay out how all the screens in an iOS application are connected, such as how tapping a button on one screen transitions, or
“segues,” to another screen. Drawing on a familiar design practice in the film industry, Apple calls this feature, “Storyboards.” This technology allows the user interface designers in a company, who may not have any coding experience, to participate much more closely in the development of an application, as the laying out of a storyboard does not simply build a mockup that needs to be coded later, but is actually creating the connections of the program’s code itself.
Step Christopher, an iOS instructor at the training company, Big Nerd Ranch, said that Storyboards exemplified Apple’s approach to technology: convenience, at a price:
Storyboards is a very Apple technology. It’s very powerful and simple to use, but you have to use it in the Apple way… you have to forget the rest of the world, and live in an Apple way, and then you can do powerful things easily, but easy in the Apple sense. (Step Christopher, Interview, May 22, 2014)
Christopher’s explanation of Storyboards reveals the flip side to the draconian control and limiting of options that Willrich said was justified in Apple in the name of simplicity. Convenience is obtained at a price. While most of Cocoa is less limiting than Storyboards, Storyboards represents this impulse at Apple taken to its logical conclusion. We can make designing an application so simple that a developer almost does not need to write any code at all. The trade-off is that a developer must do it in the specific way prescribed by Apple. Part of learning to be a Cocoa
developer, then, is in part learning to make this trade-off at some level, and learning
175
not only to accept it, but to love it, as the developer will gain productivity and pleasure in return. It is a bit like following a well-groomed ski slope—such
not only to accept it, but to love it, as the developer will gain productivity and pleasure in return. It is a bit like following a well-groomed ski slope—such