Creative Selection

This is a summary of a hybrid 💁‍♀️ narrative + 🌿 tree book on Apple's software development process. You should read the original book in addition to this summary as narrative books are not easily summarised (and narrative is a huge part of Creative Selection!) Read more about book classifications here.

Creative Selection by former Apple software engineer Ken Kocienda is a book about how Apple built software in the age of Steve Jobs.

This is a superb book if, like me, you’ve always found it curious that Apple is able to deliver software on time, at a consistent level of polish, and with a relatively low number of bugs.

What makes this account of Apple’s software engineering processes even more interesting was the fact that Kocienda was part of Project Purple — the codename for the top-secret development of the first iPhone — and was a member of a small group of designers and software engineers who essentially invented the touch-based software paradigm that now dominates the mobile world.

If you’re not a software engineer, it may be difficult to describe just how profound Creative Selection is. Consider the fact that the vast majority of software projects aren’t completed on time, are delivered with a significant amount of bugs, or are terribly difficult to use. To deliver software by a specified deadline, to do so at a certain level of polish, and to invent a new user interface paradigm while you’re at it — these achievements aren’t common, even in the tech industry.

As a software engineer, I was particularly curious as to how Apple’s practices differed from other tech companies.

I know I’m writing for a general audience on this blog, but indulge me, just for a second: there are beliefs that many of us in software hold collectively about the way software should be written: we think that product features should be defined through specification, we think that program design should happen collaboratively (and drawn out using diagrams on whiteboards or spec tools); we believe that software needs to be constantly refactored to be made maintainable and then we should write test suites to check correctness at each stage of the development process. We also think that more people should do pair programming, we believe that teams should practice code review, and that iteration cycles should be small and ‘agile’.

Kocienda’s book answers some of these questions — yes, Apple’s practices differ sharply in some aspects from conventional software development practices — and leaves other practices distressingly unaddressed. At no point does Kocienda describe Apple’s approach to code review, software testing, programming style, or refactoring. To some degree this is because he’s chosen to write for a general audience (there’s a very long section in Chapter 3 where he explains how dynamic linking works — by analogy to a recipe book) so he sticks to the large, general points that he finds most effective in explaining Apple’s results.

(And I’ll hint at one surprising aspect of Apple’s process: in developing Purple’s UI, there were no written specifications.)

Kocienda’s book is primarily a long sequence of wonderfully-told stories, which is perfect if you’re trying to understand why Apple’s process works.

(You don’t have to be beholden to Kocienda’s conclusions; you can draw your own from the stories, plus use the context to evaluate Kocienda’s proffered lessons.)

One last note before we get into my summary proper: it’s tempting to read this book as a prescriptive guide — “do these seven things, and achieve Apple’s results!” But in the introduction, Kocienda cautions against reading this book as a handbook:

“if you’re expecting to read a handbook about the “Seven Elements That Made Apple Great,” I hope you’ll see that working in the Apple style is not a matter of following a checklist.
(…)
An important aspect of this book is the way we built our creative methods as a by-product of the work as we were doing it. As all of us pitched in to make our products, we developed our approach to creating great software. This was an evolution, an outgrowth of our deliberate attention to the task at hand while keeping our end goal in mind. We never waited around for brilliant flashes of insight that might solve problems in one swoop, and we had few actual Eureka! moments.”

Creative Selection is a descriptive account of what worked at Apple, and contains what one veteran software engineer sees as the reason Apple was able to achieve the results it did. Buy this book and read it; the stories are impossible to summarise, and the book is worth getting for the stories alone.

Demos, Not Specifications

Creative Selection opens with a demo Kocienda gave to Jobs in the late summer of 2009, as they were working on the software for the first iPad. He was (as is explained later in the book) the ‘Directly Responsible Person’ for iOS’s keyboard, and was requested to show Jobs the modified keyboard he had developed for the iPad.

Kocienda opens with this story to drive home a key point: demos are at the heart of Apple’s software development process.

Decisiveness was crucial throughout. At the pre-Steve level, Scott (Forstall) was the executive editor. He was the “decider.” Every Apple demo review had a decider, the person with the sole authority to approve or not and the prerogative to declare what would happen next. Yet, even before formal reviews—say in a meeting between relatively experienced contributors like Bas and me—each of us could decide about our own portions of the work and whether we were willing to exert the effort and hours needed to pursue a new idea or make an additional refinement. Once we submitted work for a review with our team or with more junior people who were performing work on assignment, the team manager would be the decider. This practice continued on up the management chain. In particularly busy periods, Henri (Lamiraux, then-VP of iOS Software Engineering) would hold his own demo reviews for all of iOS engineering, where he was the decider before Scott. The need to keep churning out demos that could eventually be shown to Steve meant our day-to-day software development work became a pyramid of demos, reviews, and decisions building up to the top and to Steve’s final judgment.

That Kocienda was called to the demo with Steve said something about him:

When Scott chose to bring me, and not just my demo, to the review with Steve, it was his way of saying that my word on the iPad keyboard counted as much as my work on it. He widened this circle around Steve only with care. From what I could tell, Steve judged him in part on whom he chose to bring. Such hierarchically restricted access to the CEO can’t be too different from what happens with other large companies, but the way to get admission to these high-level meetings at Apple had much less to do with your place on the org chart and much more to do with your ability to make the products better. In those earlier instances when I handed over my iPhone keyboard prototypes to Henri for a Steve-level review I wouldn’t be attending, it was hard for me to realize that my demo mattered to the company but my presence at the discussion about it didn’t.

The idea that demos formed the core of Apple’s software development does a lot to demystify how they managed to create a category-defining user interface in the first iPhone.

I can attest to the fact that most software companies build software around specifications and mockups — a written description of a given feature, and a collection of images that approximates the final interface. The ‘conventional’ way software engineers work is to take these specifications (usually written by the product or program manager) and the mockups, and then implement them with feedback from a designer.

But Apple’s approach was different: they focused on interactive, working demos, and made that the minimum unit of discussion. Kocienda writes:

Consider the scenario. Two people have imagined two cute puppies. I assert mine is cuter. What do we do now? Do we have a cuteness argument? How can we? We have nothing to go on. Do I try to describe the puppy in my mind and attempt to sway you that my vision of a golden retriever puppy is superlatively cute—because everyone knows that golden retrievers are the cutest of all dog breeds—and therefore, my conjured mental picture is unbeatably cute. Do you try to make a sketch on a whiteboard of the puppy you’re thinking of but then apologize because you’re a lousy artist, so I’ll just have to take your word for how cute your puppy really is in your mind? Let’s say you’re my manager. What do you do now . . . pull rank?

The scenario is ridiculous. There’s no way to resolve this conflict. Without a concrete and specific example of a cute puppy, there’s no way to make progress.

Now, I can make this easier. Here are pictures of two cute puppies.

Now we can talk about the merits of these options. I can make my case for the cuteness of the golden retriever on the left. You might favor the lovable bulldog and attempt to persuade me that the dog-smiley happy face and single flopped-over ear make it cuter. I might argue back, pointing out the extraordinarily cute way the retriever’s paws are buried in the not-so-tall grass. If we weren’t satisfied with these two choices, we could search the web for countless others.

The point is that concrete and specific examples make the difference between a discussion that is difficult, perhaps impossible, to have and one that feels like child’s play.

This might seem like an insignificant difference, but think about the implications: Apple’s designers and software engineers have to spend days — sometimes weeks! — working on demos that may be thrown away. This is why, I suspect, most companies don’t do demos the way Apple does them: they are simply too expensive to execute on a continued basis.

But Apple does them. And Apple enforces it all the way down.

(Or at least, they used to — Kocienda notes that Apple’s software engineering culture has changed in the years since Jobs died; the few friends I have at Apple tell me that contemporary processes are different from the ones Kocienda describes. This is as it should be — note that Kocienda himself admits that process is "a byproduct of the work as we were doing it".)

Kocienda calls this process of prototype -> demo -> improvement -> repeat a process of ‘creative selection’ … hence the title of the book.

My takeaway from this section of Kocienda’s book is that demos should be the basic unit of discussion if you’re creating user-facing software from scratch. Apple’s engineers and designers would create working demos, play with them, and iterate based on usage and feedback. Ideas could come from anyone; the test was always in the performance of the demo itself. If the demo sucked — even if the idea came from Jobs himself — everyone understood that it was ok to throw the demo away.

This takeaway may seem valuable, but it’s also woefully incomplete — it’s not clear how Apple turns demo iterations — by definition ephemeral, and hacked-together — into working, maintainable software. Kocienda mentions that there’s a convergence period baked into every development cycle at Apple, where feature development is frozen and everyone just focuses on reducing the number of bugs. But he neglects to mention how these deadlines are managed, and how engineers model the internal structure of these programs.

I hope Kocienda presents a more technical version of the processes he describes in the book. I’m particularly curious as to the shortcomings of this process. My friends at Google tell me that whiteboarding and spec-writing is a core part of their process; which begs the question: could it be that the domains at which Google excels — e.g. complex distributed systems operating at massive scale — benefit primarily from a spec-driven approach, whereas ‘creative selection’ works better for user-facing products?

This is impossible  to say without actual experience, but I’d wager we’ve come within shooting distance of the truth.

The Intersection Between Technology and Liberal Arts

A second major theme in Creative Selection is the idea that Apple approaches software development through the lens of ‘the intersection of technology and liberal arts’.

Kocienda describes a number of occurrences where the approach they took was a mix of technical accomplishment and … taste. He writes:

We used the word “heuristics” to describe aspects of software development that tip toward the liberal arts. Its counterpart, “algorithms,” was its alter ego on the technical side. Heuristics and algorithms are like two sides of the same coin. Both are specific procedures for making software do what it does: taking input, applying an operation, and producing output. Yet each had a different purpose.

For example, the performance of iOS’s predictive text correction — crucial to making the keyboard usable — could be seen as an application of better algorithms, using larger dictionaries. This was the ‘technology’ or ‘algorithm’ side of things. But there is also an aspect to the keyboard development process that is subjective, and here little flourishes like key popup and key placement were matters of the software development group’s judgment — e.g. ‘liberal arts’.

Kocienda gives a host of other examples:

How long should it take for an app icon to animate up from its place on the home screen to fill the entire display? How far should you have to drag your finger on the screen for it to be possible to interpret the touch as a swipe gesture? How much should a two-finger pinch gesture allow you to zoom in on an image in the Photos app? The answers to all of these questions were numbers, and might be 0.35 seconds for the app animation, or 30 pixels for the swipe gesture, or 4x for photo zooming, but the number was never the point. The values themselves weren’t provably better in any engineering sense. Rather, the numbers represented sensible defaults, or pleasing effects, or a way to give people what they meant rather than what they did. It takes effort to find what these things are, which is appropriate, since the etymological root of “heuristic” is eureka, which (of course) comes from the Greek and means “to find.” This is where that word, “eureka,” actually figured into our development process, since good heuristics don’t come in brilliant flashes, but only after patient searches, and it wasn’t always clear to us that we had found the right heuristic even when we had. We arrived at our final decisions only with judgment and time. Heuristics are like this. They’re subjective.

I found it really cool that many such decisions were made through collective judgment, and after living with the software over a long enough time. I would have imagined that perhaps only Apple’s designers would call the shots. But within the teams that worked on Purple, an egalitarian ethos for ideas emerged.

A natural implication of this, though, is that the process of creative selection cannot be made within the context of a large team. Kocienda argues that Apple’s process calls for a small-team approach:

The culture we created is inseparable from the products we created. In my experience, this manner of culture formation works best when the groups and teams remain small, when the interpersonal interactions are habitual and rich rather than occasional and fleeting. The teams for the projects I’ve described in this book were small indeed. Ten people edited code on the Safari project before we made the initial beta announcement of the software, and twenty-five people are listed as inventors on the ’949 Patent for the iPhone. Although these two numbers measure different things, they get us in the right ballpark. These weren’t software teams of hundreds or thousands. There was a pragmatic management philosophy at play here, which started from Steve on down. Our leaders wanted high-quality results, and they set the constraint that they wanted to interact directly with the people doing the work, creating the demos, and so on. That placed limits on numbers. This had a follow-on effect as well, in that keeping our development groups small fostered feelings of personal empowerment and a sense of team cohesion. These factors are significant, especially since they’re often at the top of the list of “of dynamics that managers of too-big teams try to instill and promote. Efficient communication was yet one more oft-elusive characteristic our small teams organically engendered. The communication paths among our few team members became well traveled, and these tracks became like ruts in a road, easing the journey to our desired destinations. We always tried to reach those destinations as quickly as we could, with a minimum of dithering and delay.

The Seven Elements of Apple’s Development Approach

I’ll close this summary with the seven elements Kocienda sees as a core part of Apple’s development approach. I chose to include this part at the end of my piece — despite Kocienda introducing it at the beginning of the book — for fear that your takeaway would be “oh, so I’ll just apply these seven elements, and that’ll give me Apple-like results”.

It’s clear to an alert reader that these properties are descriptive, not prescriptive. Kocienda calls the process ‘execution dependent’ — a fancy way of saying that the organisational context and the people who inhabit it are crucial elements to make this process work.

At any rate, here are the seven elements, quoted directly from the book:

1. Inspiration, which means thinking big ideas and imagining about what might be possible, as when Imran saw how smooth finger tracking would be the key to people connecting to iPhone experiences through touch.
2. Collaboration, which means working together well with other people and seeking to combine your complementary strengths, as when Darin and Trey helped me make the insertion point move correctly in WebKit word processing
3. Craft, which means applying skill to achieve high-quality results and always striving to do better, as when the Safari team made the web browser faster and faster by running the Page Load Test, trying to understand what this test program told us about our software, and using these findings to optimizing our code.
4. Diligence, which means doing the necessary grunt work and never resorting to shortcuts or half measures, as when we persisted through the tedium of fixing cross-references to get Safari to build in the lead-up to the Black Slab Encounter
5. Decisiveness, which means making tough choices and refusing to delay or procrastinate, as when Steve Jobs made me pick the better keyboard layout for the iPad on the spot while he waited rather than just offering the two different designs Bas and I developed
6. Taste, which means developing a refined sense of judgment and finding the balance that produces a pleasing and integrated whole, as when we made the choice to offer a QWERTY keyboard layout for the iPhone
7. Empathy, which means trying to see the world from other people’s perspectives and creating work that fits into their lives and adapts to their needs, as when Scott Herz made a game to find the best size for touch targets so it was comfortable to tap the iPhone display and accommodated people with varying levels of dexterity

Each of these properties touch on a story that Kocienda tells in the book. It’s impossible to summarise narrative books, which is why I think Creative Selection is worth getting and reading in its entirety.

Fin

Kocienda’s book may be bought from his site here, and Kocienda himself may be found on Twitter at @kocienda.

I particularly enjoyed (and recommend) his WWDC 2014 talk “A Strategy for Great Work”; if you’re a software developer, I also recommend his 2011 talk on ‘Writing Easy-To-Change Code’ — if only because it hints at how Apple handles the shift from demo to maintainable codebase.

Creative Selection is — for better or worse — written for a general audience. You don’t have to be a software programmer or designer to benefit from it. But it almost certainly helps if you are.

Originally published 04 December 2018, last updated 05 June 2023.