Book Notes: “Creative Selection” by Ken Kocienda

I recently finished reading Ken Kocienda’s book (fully titled) “Creative Selection: Inside Apple’s Design Process During the Golden Age of Steve Jobs”. Ken is a software engineer who, among other things, worked on “Project Purple”: Apple’s codename for the original iPhone.

Specifically, there were a lot of interesting stories on how the original iPhone was built. More broadly, Ken writes about the process behind software creation at Apple—which he dubs "creative selection"—and how he thinks that process was a significant driver in how Apple came up with its world-class products.

I’ve written a couple other posts based in content I pulled from this book, which you can read here:

What follows is just a collection of highlights that stuck out to me when I read the book.

On Creating Automated Process Tooling

A cool story about strict adherence to a goal for making a fast tool.

When developing Safari, they quickly ran into speed and performance issues. Steve mandated that the browser be fast, so one member of the team (Don) directed that they implement a set of automated tests that would launch the browser and have it load a bunch of web pages in succession and report back a speed. Ken wrote the code for it and soon they had their “Page Load Test” (PLT) benchmark, which enabled their development process to ensure the product became “faster by never getting slower”:

Before the PLT, our editorial process was primarily concerned with feature implementation, bug fixes, and web standards compliance...These were all qualitative measures. The PLT checked for speed, a quantitative test, and it introduced an independent evaluation to every code change we made...Don held that if we heeded the PLT without fail and rejected any code changes that made our code slower, only two things could happen. Either the browser would stay the same speed...or it would get faster...our browser would become faster by never getting slower. (91)

On The Importance of a Well-Articulated Design Vision

A well-articulated is absolutely essential to a great product:

In any complex effort, communicating a well-articulated vision for what you’re trying to do is the starting point for figuring out how to do it. And though coming up with such a vision is difficult, it’s unquestionably more difficult to complete the entire circuit, to come up with an idea, a plan to realize the idea, and then actualize the plan at a high standard, all without getting bogged down, changing direction entirely, or failing outright. (111)

A well-articulated vision is the guide for the intention behind design:

a significant part of attaining excellence in any field is closing the gap between the accidental and intentional, to achieve not just a something or even an everything but a specific and well-chosen thing, to take words and turn them into a vision, and then use the vision to spur the actions that create the results. (112)

He later states:

The appeal of the iPhone wasn’t the result of piling up a bunch of features early on in our project development schedule, opening the requisite number of bugs to track the implementation of those features, and then converging, fixing them one by one as the schedule led us to ship date. Bug squashing might help to make a decent product, but it’s not the secret for making a great one. (212)

On Weaknesses

These are things Ken mentioned that struck a cord with me because they are things I struggle with. Applying these ideas to my own process would make me a better creator of software:

As a maker of products, I always turned less to the theoretical and more to the applied. (183)

I couldn’t open myself to an infinite regress of ideas at every step of accomplishing a task. It’s important to keep making progress and to keep sight of priorities. (183)

I hadn’t realized how much I relied on writing code to feel productive and happy. My programming skill suddenly didn’t matter, and I didn’t have an intuitive sense for what I needed to do to be successful as a manager. (132)

As a programmer and self-professed geek, possessed of a typical geek programmer’s communication skills, it was a revelation to me that both the setting and the solution to my hardest technical problem turned as much on the social side of my job as it did on the software side. (130)

On Taste and its Role in Holistic Design

Taste is developing a refined sense of judgment and finding the balance that produces a pleasing and integrated whole. (183)

The small-scale justifications must contribute to a scheme larger than themselves. The design responsibility expands to balancing the many individual refined-like responses against the other side of the taste equation, the attempt to create a pleasing and integrated whole. (186)

Miscellaneous Quotes

My new job was open-ended. I was expected to find, create, and contribute to projects that made our software better.

Persist too long in making choices without justifying them, and an entire creative effort might wander aimlessly. The results might be the sum of wishy-washy half decisions...Developing the judgment to avoid this pitfall centers on the refined-like response, evaluating in an active way and finding the self-confidence to form opinions with your gut you can also justify with your head. It’s not always easy to come to grips with objects or ideas and think about them until it’s possible to express why you like them or not, yet taking part in a healthy and productive creative process requires such reflective engagement. (184)

the appearance of a product should tell you what it is and how to use it. Objects should explain themselves. (187)