Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

by Ken Kocienda

Richard started at Apple during my second week struggling to make Mozilla do more than build, launch, and crash. On his first day, Don and I gave him a full update on everything we had done, our open source strategy, Don’s discussions with outside companies, a listing of the candidate browser source code options we had considered, our decision to focus on Mozilla, my Building the Lizard document, and the bolts-protruding-from-the-neck, crash-prone hulk of a browser produced by following those steps. Richard asked, “How long have you guys been working on this browser project?” His tone indicated that he wasn’t impressed. Don answered, “Six weeks.” Richard scrunched up his face in confusion at our lack of progress. He launched into a series of technical questions, delving into details. Was he trying to identify some valuable nugget we had missed? As we went on, it seemed Richard was too polite to ask the question really on his mind: “What on earth have you guys been doing?” Later on, when Don and I had a chance to chat by ourselves, we concluded that Richard simply didn’t understand how hard this browser project was going to be. That would soon change. We agreed that we liked our new teammate, and we could look past any gruff behavior because it was accompanied by an eagerness to get going. We’d give Richard a week or so to get his computer and office set up, then we would talk to him about the project some more. It didn’t take Richard that long to get settled in. Two days l...

“When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned.”

His thought process amplified his technical acumen.

In contrast, Don and I were hoping Mozilla would pan out somehow. I was trying to get the open source behemoth to build on the Mac, with little thought beyond that. I had no comparable plan, goals, nongoals, tight schedule, or technical shortcuts.

More than anything, this difference in thinking led to the differ...

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.

Their software style was the Hemingway to Mozilla’s Faulkner.

[Edison] sat one night thinking about the problem, unconsciously fingering a bit of lampblack [a pigment made from soot] mixed with tar which he had used in his telephone. Not thinking what he was doing, he rolled this mixture of tar and lampblack into a thread. Then he noticed what he had done, and the thought

Hard work is hard. Inspiration does not pay off without diligence.

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.2 (Emphasis added.)

“Actually, here’s what I have to say to those people who said our stores would most certainly fail,” and he clicked to a newly

Vince Lombardi, the link becomes illuminating and Apple-like.

“Gentlemen,” he said, “we have a great deal of ground to cover. We’re going to do things a lot differently than they’ve been done here before . . . [We’re] going to relentlessly chase perfection, knowing full well we will not catch it, because perfection is not attainable. But we are going to relentlessly chase it because, in the process, we will catch excellence.”

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.

“I think if you do something and it turns out pretty good, then you should go do something else wonderful, not dwell on it for too long. Just figure out what’s next.”1

Kim Vorrath,

Think of a cute puppy.

Most people make the mistake of thinking design is what it [a product] looks like. People think it’s this veneer—that the designers are handed this box and told, “Make it look good!” That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.7