Book Review: Rapid Software Innovation at Steve Jobs's Apple
Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs, by Ken Kocienda
This book really caught my attention. It does something rare: it portrays, accurately, what it’s like to do demo-driven development of user-facing software. As one of the many people (millions of us?) who has spent years developing software this way, I found it fascinating.
Ken Kocienda worked on two pieces of software you’ve probably used, perhaps many times a day: the Safari browser and the innovative iPhone on-screen keyboard. Much of the book is the two stories of developing them. He worked for Steve Jobs’s Apple, and that means he worked the way Steve Jobs wanted people to work. I couldn’t have told you for sure how that was, but if you’ve written consumer software this century, you probably use the demo-driven approach for your pre-launch software, and you probably believe, suspect, guess, or have heard it rumored, that the demo-driven approach goes back to Steve Jobs. You probably also use its close cousin, launch-and-iterate, for your post-launch software.
The demo-driven approach has long seemed to me to be the engine that drives day-to-day software innovation, and it is at the heart of Ken’s story. He and his coworkers built demos and mock-ups, showed them to each other, discussed possible improvements, made some of the improvements, and repeated this over and over. At less frequent intervals, they showed the demos to their bosses and others, and at less frequent intervals again they showed them to further-flung executives and to Steve Jobs.
Safari
Ken tells the story of building Safari from the start. It was 2001. Jobs decided Apple should build its own browser. Ken and Don Melton joined Apple and began the project. Just the two of them! A daunting task that would involve working from existing open source browser code, such as Mozilla or Konqueror. Ken downloaded the 1.5 million lines of Mozilla code, which had never been built on a Mac, and got to work. Their manager expected a demo quickly, and was disappointed when one hadn’t materialized in a week or two. After 6 weeks, Ken got the code to build. He fired it up. It crashed. Repeatedly.
Richard Williamson joined them as a third member. Two days later Richard his first demo. He had downloaded Konqueror for Linux, wrote a thin layer of code to implement the Linux calls it needed on Mac OS X, displayed its output to X Windows for Mac, and after two days he had a browser. It loaded pages. It processed clicks on links.
This is perhaps the book’s single greatest example of how good demos are moving a project forward quickly. Suddenly, they knew that the Konqueror path was workable. A huge question of risk was removed. The Mozilla and Konqueror paths initially seemed similar, but it’s a good thing they tried both, because the Konqueror path progressed 15x faster. And one learns things from the details of demo successes. I wouldn’t have been surprised if after this breakthrough someone else had turned around and gotten a Mozilla demo working in 2 more days.
Ken makes much of the fact that Richard was laser-focused on getting to a demo, in a way that Ken and Don had not been up to that point, and that that made all the difference. He credits Richard with teaching him the importance of getting to a demo. I would agree that it’s a crucial practice in getting things done!
There’s more to the Safari story, and there are other stories, but the longest story he tells is that of the iPhone on-screen keyboard.
The iPhone Keyboard
The iPhone project started with the certainty that the keyboard would be on screen, but early in Ken’s time there, it became clear that that decision created the biggest unsolved blocker for the iPhone software. How was this going to work?
If you don’t consciously understand how your on-screen keyboard works, it’s worth summarizing: it has keys in the same configuration as any physical keyboard, but the software knows that you’ll often miss by quite a bit, and it fixes that by guessing you meant to press nearby key that fits into a real word or a name in your contacts. We know this in 2022. In 2005 and 2006, they didn’t have a clue.
To start figuring out what to do, the team declared a hackathon, to put themselves into overdrive. Everyone on the team built a series of quick demos. The approaches were far-flung. Some keyboards used chords. One used Morse code (lol). Richard said early on that “everyone is making their keys too small,” and that sparked a series of demos by him and by Ken, with the two trying each others’ keyboards and talking often.
One of those demos used large keys with multiple letters on each, that were touched by tapping to get the middle letter on a key, swiping to the side to get the left or right letter on the key. Ken was on his sixth prototype when he decided that the key was to leave the letters in their usual places, but group them in groups of two or three that shared a single rectangular key. Any series of clicks was ambiguous, so Ken assembled a word dictionary, and showed suggestions from the dictionary above the keyboard.
At about this point, four weeks into the hackathon, with no clear end in sight, there was a huge bake-off meeting with all the demo keyboards for Scott Forstall. The meeting is a two-page nail-biter. None of the keyboards let him type accurately. Ken was last on the schedule. In fact, Ken was running on different hardware than everyone else, and as a result the program manager running the meeting forgot he was on the schedule and declared the meeting over. Ken describes a moment of freak-out, then gives Scott the device. Scott unadjourns the meeting. Scott quickly types out “Scott”, then “Scott is my name.” This worked!
A day later Scott ended the hackathon and declared Ken the engineer responsible for the final keyboard. Once again a demo had been the best proof of which direction worked. I always list the iPhone and Android phones as one of the half a dozen great steps forward for consumer software in the past 20 years, and the software keyboard is a big part of what gives it its final form. At the same time, it was a hard open innovation problem, whose solution, even in broad strokes, was unknown even weeks before it emerged. It’s a great moment to see up close.
There’s quite a bit more to the iPhone keyboard story – notice especially that we haven’t used the word probability yet. Ken’s stories also get a lot of fun out of describing the handful of demos he does for Steve Jobs during that time. As I recall, Steve does not say that Ken’s software is shit, but the famous idea that he might adds to the drama. Ken’s book demonstrates the value of demos – the value of really building things and trying them out – and it’s an enjoyable reminder of why we build software the way we do, certainly everywhere I’ve worked in the last 20 years. I also remember before we as an industry figured these tricks out. It a hard slog to develop software without knowing that you should try to build a working demo once a week or once a day.
Further Reading
The roboticist Rodney Brooks wrote this week, in great detail, about riding in Cruise robotaxis in SF. His summary is that they work! My summary of his article would have been the opposite. In any case, his account is very detailed and enjoyable.