ken kocienda's lessons from apple

The Talk Show (of Daring Fireball) had an episode with Ken Kocienda, who did pioneering work on the Safari browser and the iPhone and who recently wrote the book Creative Selection about his work at Apple and the culture their during Steve Jobs' return.

Getting the onscreen keyboard right (and thus refuting the "Crackberry"-wielding naysayers who loved their physical keyboard, as well as avoiding a repeat of the Egg Freckles perception issue that hastened Newton's demise) was a huge challenge, and at one point the entire iPhone (then codenamed "Purple") engineering team pivoted to solving it, having a "Keyboard Derby" to demonstrate different approaches. 

Here was Kocienda's winning entry:

You'll notice it won the derby, but the launch product returned to a more normal one-key-per-letter layout. This layout was a bridge from earlier attempts at predictive text on phone keypads to the autocorrect we rely on today. (It's odd how when they pivoted back to one letter per key - needed for typing in names and purposeful misspelling that the dictionary wouldn't know about - the end result looked an awful lot like PalmPilots had been doing over along.)

One detail that doesn't get mentioned in the book but they talk about on the podcast is the iOS checkerboard that would appear when the iPhone scrolled past what it could render, until the true content could catch up. (You don't see it much these days but apparently the code is still there.) It was a great example of how keeping up the feeling of true physicality was so crucial on the early iPhone, and was more important than being "honest" about what could be rendered.

That need for speed predates the iPhone and goes back to when it was a significant goal of Safari - he cites Don Melton's mantra of "our browser will become faster by never going slower", that is, every check-in of new code had to run a speed performance test and find some way to compensate for any speed loss before it could become part of the product. (This was the PLT, or "Page Load Test" - I think that tests final results - rendering page speeds in this case - are holistic and therefore superior to superficially similar tests-on-checkin, such as unit test coverage.)

The book has a lot of other great stories of bits of advice - like how Richard Williamson's 2 day "hack Konqueror to run on Mac" blew away Kocienda's much longer effort to get Mozilla compiled and running, and thus became the root branch of nearly all browser platforms, which led to Kocienda musing:

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. 

We learned all this from Richard. He changed the way we worked. 

 Another great point was algorithms vs heuristics... for things like the PLT, you can take a persnickety algorithmic approach, but for many other things you can and should rely on the heuristics of taste and feel - 

We used algorithms and heuristics like they were the left and right sides of our collective product development brain. Employing each involved an interplay of craft and taste, and we always tried to strike the correct balance. Algorithms and heuristics must coordinate to make a great high-tech product. Fast web page loads, correct insertion point movement, efficient code, lovely animations, intuitive gestures, and well-considered built-in behaviors are all essential in a product like the iPhone. Our goal was comfortable technology and computer-enabled liberal arts, a combination of both. 

However, it’s crucial to make the right call about whether to use an algorithm or a heuristic in a specific situation. This is why the Google experiment with forty-one shades of blue seems so foreign to me, accustomed as I am to the Apple approach. Google used an A/B test to make a color choice. It used a single predetermined value criterion and defined it like so: The best shade of blue is the one that people clicked most often in the test. This is an algorithm. 

At Apple, we never considered the notion of an algorithmically correct color. We used demos to pick colors and animation timings, and we put our faith in our sense of taste.

That was the part of the path to get to the legendary accomplishments of mid-2000s Apple:

A small group of people built a work culture based on applying the seven essential elements through an ongoing process of creative selection. 

Expanded out, it reads like this: 

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.

Anyway, the book is a great read that doesn't overstay its welcome.