Book Notes: Creative Selection
Creative Selection is a memoir by Ken Kocienda about his time at Apple. It is concerned with the conditions required to do good work. The author shares the approach Apple takes to do good work.
The Demo
The book begins with a demo of the iPad keyboard to Steve Jobs. The author is waiting nervously outside of Steve’s office.
Familiar characters in the Apple world–Henri Lamiraux, Scott Forstall, Bas Ording–are introduced right away. They are all a model of efficiency and taste.
So, is the demo of the keyboard.
“We only need one of these, right?”
In mere moments, the whole is understood by Steve. The important details are synthesized. The key questions are asked. A decision is made.
Even the discussion Steve used to arrive at his conclusion was spare and minimal. Note how Scott introduced my demo with just enough words to communicate to Steve what was next on the agenda, where he should turn his attention, and who I was. I, in turn, used the minimum number of words necessary to direct Steve’s attention further, so he knew exactly what to look at. After that, Steve looked carefully at the software and asked me succinct questions to see if the work could be made simpler.
The Crystal Ball
The book circles back to when the author first arrived at Apple. He had come from a failing startup called Eazel. Eazel built a failing App for the Linux GNOME desktop system called Nautilus.
The second chapter contrasts the way Nautilus was shipped with the way Apple ships demos and then products.
The author worked with the legendary Don Melton at Eazel. Don had previously worked on the Mozilla web browser at Netscape.
The author and Don are hired to build a web browser for Mac OS X. The web browser that will eventually become Safari.
However, they are six weeks into the project and they are mostly fucking it up. They have little progress to show until they bring Richard Williamson on to the team.
Richard is a lightning bolt of a programmer. He is able to get Konqueror up and running on Mac OS X in two days.
He hacks away at the code. He takes shortcuts. But he knows what his goal is and he gets the job done in blazingly fast time because he also knows what his non-goals are.
This is the lesson the author and Don learn: a plan, goals, non-goals, tight schedules, technical shortcuts.
Over time, Don and I began to understand and absorb the model Richard showed us. Look for ways to make quick progress. Watch for project stalls that might indicate a lack of potential. Cut corners to skip unnecessary effort. Remove distractions to focus attention where it needs to be. Start approximating your end goal as soon as possible. Maximize the impact of your most difficult effort. Combine inspiration, decisiveness, and craft to make demos.
The Black Slab
After the demo, the author, Don, and Richard had to re-asses where they were at and how to move forward. And asses why working with Konqueror was so much easier than working with Mozilla?
At just over 120,000 lines, Konqueror was less than one-tenth the size of Mozilla. At first, we couldn’t believe there could be such a difference between two bodies of source code that performed the same function.
Don explained. The Mozilla project leaders had designed a system they hoped would turn their software into components they could snap together like LEGOs. However, this scheme required reams of extra boilerplate code…Now that we saw the implications of this engineering decision and the resulting 10:1 ratio of Mozilla code to Konqueror code, it seemed obvious that their component notion had gotten wildly out of hand. Mozilla was bloated, unwieldy, and troublesome.
The Konqueror team had taken the opposite tack. Their code was lean and lithe. They prized brevity. Their software style was the Hemingway to Mozilla’s Faulkner.
Projects are 1% inspiration and 99% inspiration. In this case, Richard’s initial demo was the 1% inspiration. This was followed by the tedious work of taking this demo and creating a polished product that users would love. All the hacks and work arounds had to be removed and fixed.
It took two months just to get to an empty white window.
And then even more weeks to load http://yahoo.com and render The Black Slab.
I ran down the hall to get Don. When we got back, I quit the browser and loaded the Yahoo! main page again. We held our breath through the same pause … and we then saw the same black rectangle. The browser had finally done something!
One Simple Rule
The team grew from this point on.
And Steve had a new mandate: the browser would be judged by its speed. How fast it loaded and rendered pages.
Don had an idea to create a test program to measure browser speed. The author implemented this test program and called it the Page Load Test (PLT).
There was One Simple Rule: the browser would become faster by never getting slower. Every code change had to maintain speed or make the program faster.
As progress continued, the browser was christened Safari.
And Steve started rehearsing for the keynote where Safari would be revealed to the world about four weeks ahead of time.
This was one of Steve’s great secrets of success as a presenter. He practiced. A lot. He went over and over the material until he had the presentation honed, and he knew it cold.
When Steve spoke to a slide, he went fully into his keynote persona. His tone of voice, his stance, his gestures, everything was exactly as if he were presenting to a packed house.
And Steve picked his words very carefully. Words have meaning. Words impart vision. Words coalesce a team. Words create clear rules.
After Steve showed the Safari icon, he clicked to the next slide. It had a single word: Why? Steve felt the need to say why Apple had made its own browser, and his explanation led with speed. Some may have thought that touting Safari performance was just marketing, a retrospective cherry-picking of one browser attribute that just happened to turn out well.
The Hardest Problem
After Safari shipped, the author moved on to be the Directly Responsible Individual (DRI) for the HTML editing features in Mail.app.
…directly responsible individual (we pronounced it as D-R-I in conversation), the person who has to do whatever is necessary to develop a piece of hardware or software, some technology, some critically needed thing–the DRI was the person with their butt on the line.
The author fumbled around for months not making any significant progress on the HTML editing project. This was a hard problem to solve and the author had gone into “dark mode”. He finally sat down with Don. Don suggested the author meet with Darin Adler and Trey Matteson from the web browser team.
A meeting with Darin and Trey ensued in the upcoming days. The author spent about a half hour meandering about the problem he was trying to solve.
When it came time to discuss a solution, they told me that I should clean up my code. Over months, as I struggled, I had scattered special-case insertion point functions throughout my project. They told me that was a mistake, but their specific software prescription–to gather the code back together into a single C++ class, which they proposed we call VisiblePosition–was about more than tidiness. It represented an important technical insight: When software behavior is mysterious, get more organized. My insertion point code needed to be businesslike as a baker looking at a properly filled out order form to determine the correct words to write on a cake.
The solution to the hardest problem that the author faced was as much about collaboration and communication as it was about software.
The Keyboard Derby
The author was up for a new challenge after the HTML editing project was over. And he was sore from not being made a manager on the Safari team.
The author met with Scott Forstall and took an open position for manager of Sync Services. The customer facing name for this product at the time was .Mac.
The author was miserable being a manager in short order. This is a common pattern where individual contributors that are used to being makers are put in a position where their main output is having meetings.
Also, Sync Services was technically challenging but it wasn’t a glamorous project at Apple.
This viewpoint counts for more than you might think. Apple is customer-focused. The company always sought to give people convincing reasons to buy its products. If the marketing department wasn’t interested in telling people about sync, then the feature was something Apple felt it needed to do, not necessarily something that it wanted to do or was excited about doing.
Apple is a demo-focused culture. How do you demo sync?
The author had heard mumblings of a secret project in Scott’s group. And one day, without warning, the author sprung the news on Henri that he wanted to quit his current assignment. Luckily for the author, this didn’t end in complete disaster.
After a few back and forth meetings:
Henri called me into his office. He closed the door. We sat down. He asked me to sign a piece of paper. It was a nondisclosure agreement, an NDA,…
I didn’t hesitate.
Then Henri told me. “Yeah, we’re making a cell phone. Its code name is Purple.”
At this point in the project, the only hardware device that existed was called a Wallaby. A phone-sized prototype with a multitouch display. The Wallaby was tethered to a board and the board was tethered to a Mac that supplied the computing power to the display.
Once again, the author started working text editing code for this new platform.
There was steady progress on the project except for one glaring case: the onscreen keyboard. It just didn’t work, yet. An immediate halt was called on all tasks and all 15 programmers on the team were tasked to work on keyboard prototypes.
Any and all ideas were to be explored. ASAP.
This period of intense work culminated in a demo for Scott Forstall. After a few attempts, the author came up with an idea that consisted of a QWERTY keyboard backed by an autocorrecting dictionary. The demo was a hit.
Scott turned around to me and said, “This is amazing!” Everyone else was silent for a moment, then Scott’s question started raining down.
The author’s prototype won the derby, but there was much work ahead that still needed to be done to turn it into a product.
QWERTY
There were early meetings with Phil Schiller and Tony Faddell. They were not impressed with the keyboard prototype. The author hints that the reason was partly political.
Over many iterations, the keyboard improved. The dictionary was broadened. The algorithm was tweaked for corner cases. Autocorrect was toggled on by default. The size of keys was adjusted. Key groups were split into smaller single keys like one would expect on a PC keyboard. Virtual tap areas were added. Animations and sound were added.
Iteration after iteration after iteration.
These iterations were driven by the team’s taste.
Taste is developing a refined sense of judgement and finding a balance that produces a pleasing and integrated whole.
Convergence
Convergence was the term we used to describe the final phase of making an Apple product, after the features had been locked down and the programming and design teams spent the last three or four months fixing bugs and polishing details.
The keyboard was feature complete but bug after bug after bug had to be squashed. There was a bug that harkened back to the failed Newton. It was one of many.
One major convergence point was the first untethered hardware device. The real industrial design with the real glass screen loaded with the real software untethered from the Mac. It was still called by its codename Purple. But the project was coming together.
Naturally, I was most interested in the keyboard. I typed out a few words in the Notes app. They keyboard worked without a hitch. … As I handed the device over, I had no question in my mind.
I wanted one.
The Intersection
The iPhone was announced to the world in January of 2007 and there were some skeptics. Including another famous Steve:
“$500? Fully subsidized? With a plan? I said that is the most expensive phone in the world, and it doesn’t appeal to business customers because it doesn’t have a keyboard, which makes it not a very good email machine.”
But the iPhone project succeeded. It succeeded because Apple sits at the intersection of technology and liberal arts. The author describes what makes Apple great:
- The demo driven culture
- The development process
- The people and their commitment
The author further elaborates on the attributes of the development process:
- Inspiration
- Collaboration
- Craft
- Diligence
- Decisiveness
- Taste
- Empathy
The is the central thesis of the book.
A small, group of passionate, talented, imaginative, ingenious, ever-curious people built a work culture based on applying their inspiration and collaboration with diligence, craft, decisiveness, taste, and empathy and, through a lengthy progression of demo-feedback sessions, repeatedly tuned and optimized heuristics and algorithms, persisted through doubts and setbacks, selected the most promising bits of progress at every step, all with the goal of creating the best products possible.
At This Point
The iPhone was released to the public on June 29, 2007. The author went on to work on multi-touch gestures for the iPad.
As all things do, the iPhone project ended. As did Steve’s life.