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

by Ken Kocienda

speed.

Steve wanted our browser to be fast, really fast at loading web pages from the internet, much faster than Microsoft Internet Explorer, the default browser o...

At Apple, we always tried to deliver the best product out of the box, and in addition to this speed directive, we needed to deliver a browser with a well-rounded set of features—excellent bookmark management...

Yet the team jelled around our speed goal. The challenge ...

In addition, we were keenly aware that product replacements like the one we were attempting could be a delicate business.

Once Apple made our new browser the default on the Mac, none of us wanted our users to question whether we had given them an improved web surfing experience.

Steve reasoned that a speedy new Apple browser would be the best way to make people forget about Internet Explorer and to feel go...

Speed was also part of Steve’s vision for the future of int...

Everyone knew faster days were coming, and Steve wanted our browser to be ready right away for the increased data that would be flowing through internet connections as they got quicker.

Our code had to keep up.

Steve thought speed was the long-term key to ...

Page Load Test,

but we soon took to calling the PLT.

this single number became the key element to Don’s plan. He issued a managerial edict: No more code changes without running the PLT.

What does this PLT pronouncement mean, and why was it important?

On our browser team, as in most serious software development efforts, we followed an editorial process to make changes to our source code. Whenever I finished editing some code, I would write a detailed summary of what my edits did, what feature it implemented or what bug it fixed, and how well I thought my code change accomplished these goals. Then I would find a teammate to review the work with me. The code review process often led to round after round of reviewer feedback, improvements, and requests for re-review. Once everything passed muster in the peer re...

Before the PLT, our editorial process was primarily concerned with feature implementation, bug fixes, and web standards compliance—how well the...

These were all qualitative measures. The PLT checked for speed, a quantitative test, and it introduced an independent evalu...

Correctness and speed now went h...

Don held that if we heeded the PLT without fail and rejected any code changes that made our code slower, only two things could happen. Either the browser would stay...

our browser would become faster by never getting slower.

Running the PLT against new code became a daily ritual, sometimes an hourly one.

Most code edits had no effect on performance, but some inevitably did, and as long as the change was in the faster direction, then all was well. We sometimes had happy accidents too—unforeseen speedups stemming from changes to remove lingering FIXMEs.

Higher-quality code often performs faster.

There could be no exceptions to the PLT speed rule—Don

When an essential bit of new code caused a slowdown, things could get tricky.

Finding remedies for speed setbacks typically involved th...

software optim...

We should forget about small efficiencies, say about 97% of the time:

premature optimization is the root of all evil.

Optimization is the process where programmers try to make code execute faster. Isn’t that what the PLT was all about? So, isn’t optimization a good thing?

Not always,

optimization is bad about 97 percent of the time.

To make speedy software, program instructions must be as efficient as possible,

but it’s not always straightforward to know which instructions will be fast to execute.

Since some instructions encapsulate a higher order of conceptual complexity than others, some instructions take longer, perhaps much longer, to execute than others.

Sophisticated software is built on an elaborate and interlocking web of dependencies between separate components, and dealing with these relationships is an inescapable part of writing complicated software like a web browser.

how difficult it can be for a programmer to know how fast a specific piece of code might execute just by looking at it, even if the content of the instruction is perfectly easy to understand.

This gets to the heart of why the PLT was such an important test.

The PLT helped us to understand what our programming instructions were doing along the essential axis of speed and showed us precisely when and where we were introducing slowness to our source code.

The PLT told us when to pay attention to the “small efficiencies” Knuth mentioned. It was our 3 percent escape hatch, a way to know for sur...

We were sure each optimization we did was helping to keep performance heading...

It’s common for programming teams to make their code work correctly first and then turn to speeding it up only once most of the bugs are fixed.

Front-loading feature work and back-loading performance optimizations are typical.

Yet, when features take longer to complete than expected and the delivery schedule can’t be shifted, management might have no choice ...

The PLT helped us to correctly distribute optimization work throughout the entire project.

Yet, even with the PLT, optimizing remained a tricky business, and sometimes the search for performance improvements led to detailed investigations on why things work the way they do and how they might work differently.

When we deemed such features too important to skip but couldn’t figure out how to add them without causing such slowdowns,

we instituted a trading scheme, where we found speedups in unrelated parts of our existing source code to “pay for” the performance cost of the new features.

When we looked around for code to perform this kind of payoff optimization, we typically targeted code we knew well and...