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

by Ken Kocienda

it would be the difference between writing software and influencing what software got written.

Demos served as the primary means to turn ideas into software. The setup of these demo review meetings reveals how we went about making our software great.

This statement includes the assumption that Apple made making great software an important goal to begin with. We did, and that came straight from Steve.

What’s more, Steve wasn’t merely interested in paying lip service to this goal. He demanded action,

and so the software team produced demos in a steady stream, and whenever there was interesting new work, Steve found the time to attend a demo review so he could see it.

His involvement kept the progress and m...

Decisiveness was crucial throughout.

Every Apple demo review had a decider, the person with the sole authority to approve or not and the prerogative to declare what would happen next.

Clear decision rights

The need to keep churning out demos that could eventually be shown to Steve meant our day-to-day software development work became a pyramid of demos, reviews, and decisions building up to the top and to Steve’s final judgment.

Approving work wasn’t the only decision to make.

the way to get admission to these high-level meetings at Apple had much less to do with your place on the org chart and much more to do with your ability to make the products better.

Even the discussion Steve used to arrive at his conclusion was spare and minimal.

This push for simplicity had a purpose. Even though he was a high-tech CEO, Steve could put himself in the shoes of customers, people who cared nothing for the ins and outs of the software industry.

He never wanted Apple software to overload people, especially when they might already be stretched by the bustle of their everyday lives.

He believed that stripping away nonessential features made products easier for people to learn from the start and easier to use over time.

He wanted products and their software to speak for themselves.

Steve used demo reviews to judge for himself whether features met this basic usability standard.

the best way to answer difficult questions like these was to avoid the need to ask them.

Steve’s brand of decisiveness permeated Apple.

He surrounded himself with people like Scott, Greg, Henri, and Bas at...

they could make good decisions without lon...

How many people in a corporate setting can do this? Good highlight of this key characteristic shared by top Apple executives

When Steve questioned me, it was a test of my decisiveness and whether I could make my demo ...

Seeing good work wind up on the cutting room floor was part of the job.

Demo reviews were also part of Steve’s effort to model the product development behaviors he wanted us to use when he couldn’t be present.

the whole software organization kept meetings and teams small to maintain efficiency and to reinforce the principle ...

sentences.

Love this continual theme of minimalism that runs through Steve Jobs...feels exceptionally rare in a rich and powerful person

Free software made good solutions to common problems readily available,

General Public License (GPL)

rather than restricting the privileges of software users, the GPL expands them, guaranteeing that everyone can get no-cost access to software source code and can study it, modify it, use it as is, or treat it the basis of new projects.

This sounds free indeed, but the GPL had its catch.

If you wrote software based on code covered by the GPL, you were required to publish your sof...

The expectation was that this would create a virtuous cycle in which coders were continuously building on each other’s efforts to the betterment of all, rich or ...

If you don’t work in the software industry, Richard Stallman might be one of the most influential people you’ve never heard of. Over the decades, free software has ...

His GPL drives the development of the Linux operating system, and Linux is the core software running on Android smartphones, in the data centers for Google, Amazon, Twitter, and Facebook, a...

Without the long-term influence of Stallman’s ideas and all the free software inspired by them, the internet...

There would likely be no web search engines, streaming music, or YouTube. No Wikipedia either. No chat apps. No social networks. No smartphone...

Chief among our missteps was failing to conceive of our software as a single product instead of as a set of separate projects.

We never figured out how to integrate the pieces. Nothing worked smoothly. Our software update feature was riddled with bugs that often broke programs while trying to update them.

since they believed the internet would be an important part of the future of computing, communication, and commerce, they wanted Apple to control its own destiny in this burgeoning technology domain.

They wanted the flexibility to improve the company’s internet software at will, and having an in-house browser was the first step in this strategy.

this browser replacement initiative became our job. It involved two interlocking goals. First, make a web browser app. Second, create a web technology toolkit that would make it easy for Apple’s third-party software developers to incorporate web features into their software, from downloading text and images to displaying entire web pages.

From the perspective of a programmer, web browsers are fiendishly complicated.

a web browser’s major subsystems: content (text and images), styling (fonts, colors, and placement), and scripting (dynamic behaviors like checking a form before you submit it). He told me about the alphabet soup of published standards to cover these respective technical areas: Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), and the JavaScript programming language.

We had a trick up our sleeve.

We wouldn’t be starting from scratch, as had been done at a web-browsing pioneer like Netscape. As a result of the free software movement and the browser wars, Netscape had published its source code for Mozilla.

On the upside, Mozilla represented a huge investment in web technology, so we could use it to avoid having to reinvent the wheel at Apple. The downside was that the source code base was hard to work with because it was huge,

The ones with previous experience at Netscape took the unstated hint from Don, and none wanted any part of making another browser. My recent difficulties with Mozilla gave me an inkling about why they felt that way.

we simply didn’t know how to bootstrap a big project and set it on a course for success.

software demos need to be convincing enough to explore an idea, to communicate a step toward making a product,

even though the demo is not the product itself.