Jobs’ product thinking, and the birth of Safari.
Specially set a [leaning reading] section for reading, screen some books worth reading, and provide some book excerpts. I hope you have a good book on hand to allow the reading movement to continue.
SAFARI: What Jobs wants is faster
To this day, I still clearly remember the cold and cold feeling in my hand at that moment, Steve solemnly announced to everyone: Apple has developed its own web browser. In a split second, our super secret-this 18-month development project-became known. Steve announced to everyone that Safari loads web pages not only a little faster than IE, but a full three times faster.
What Jobs wants is faster
There is news from management. Steve Jobs has decided on his criteria for judging our browser project. There is only one key point: speed.
Steve wants our browser to be fast, and to load web pages from the Internet fast enough, it must be much faster than the default Microsoft IE browser used on Mac computers, because the purpose of our browser exists Is to completely replace the IE browser.
At Apple, we always try to provide the best products out of the box. In addition to speed, we also need to provide a complete set of features for the browser. Among them, excellent bookmark management, streamlined user interface, etc. Two items occupy the most important positions on the development list. However, our team is still focusing on the goal of increasing speed. These challenges have given us clear goals.
Speed is also part of Steve ’s insights into future Internet trends. Steve hopes that our browsers will be ready for the coming wave.
Partial optimization of the software must be abandoned to ensure speed
Even among programmers, there are very few people who can be called famous computer scientists, but Gartner definitely can afford this title. Here’s what he said about optimization:
Programmers waste a lot of time thinking or worrying about the speed of non-critical parts of the program. In fact, if debugging and maintenance are considered, these efforts to improve efficiency actually have a very strong negative effect. We should give up a trivial efficiency improvement, and in 97% of cases, premature optimization is often the source of errors.
Let’s take a look at this example. Suppose I invite you to a demonstration in my kitchen, I let you:
Take a can of mustard from the refrigerator.
You can easily accomplish this task because my kitchen stocks this condiment. Obviously, executing this instruction willSaves more time than executing this equivalent length command:
Go to the supermarket and buy a can of mustard.
Because some instructions contain more complex commands, these instructions take longer to execute than others. What does this have to do with optimization? Here are the instructions you need to complete other kitchen tasks:
Remove everything from the refrigerator.
Place everything on the counter.
Optimize it by adding an instruction:
Remove everything from the refrigerator.
Place everything on the counter.
Complete the task with the least number of round trips.
The third instruction suggests speed for this task. Regarding the number of round trips between the refrigerator and the counter as a constraint, we can reasonably believe that if the number of round trips is reduced, the entire operation process can be completed faster.
Is this correct? The above optimization path causes the following problems. This may work if you pick up and unload a large number of items at once, but is it really the case?
What if I try to put together a jar of mustard and mayonnaise, a carton of milk, a butter stick, and a plate of leftovers from last night? This caused a malfunction, didn’t it? If I spill or break something, do I have to spend time cleaning it to ensure the task is “complete”?
If I look back and think about what the instruction “Complete the task with the least number of rounds” means, I might still think that the goal of the task is to minimize the number of round-trips between the refrigerator and the counter-but this Is it true intention? I don’t know, this is just my best guess. I actually don’t have enough information to confirm the purpose of this task.
This scenario tells us why experienced programmers like Gartner issue warnings about optimization. Sometimes, during browser development, even the best survey results and “innovative thinking” are not enough. Many times we will find that we can’t find a way to increase the functionality without affecting the speed. No optimization is simple and not always fun.
Safari: a name everyone likes
As the project launch date approaches, Apple ’s marketing department has begunIt is the beginning of solving the problem. Although it is difficult to define such a vision, there is no doubt that it is more difficult to complete the entire job.
You need to come up with a solution to the problem, come up with a plan to realize the idea, and then complete the plan to a high standard, without getting into trouble, changing the direction of your efforts, or failing completely. Perhaps the most stressful and disturbing is that your approach, language, and vision have not started well, and even if you go all out, they will not lead you to success.
In the early days of the browser project, Steve told us that he wanted the browser to be fast enough. Don gave us the rules to achieve this: never make any changes that slow down the browser.
In addition, PLT gives us a way to achieve our goals. The browser team embeds PLT into our daily workflow, and we use test results to measure and monitor our progress. Almost a year later, when we were ready to launch Safari, Steve could tell the world in a very direct way that we were successful.
Before the beta was announced, our Safari team only had 10 people responsible for editing the code, and the iPhone 949 patent listed only 25 inventors. Neither team is a software team with hundreds or thousands of developers. Since Steve, the company has hidden a practical management philosophy from top to bottom.
Our leaders want high-quality results. They set a variety of rules, including direct communication between managers and front-line employees who make sample programs. This requirement limits the number of teams and has a deeper impact. Our development team must require that each member is good enough and team cohesive.
These factors are important because they keep people motivated at all times, and that’s what the leaders of very large teams have been working on. High communication efficiency is another inherent feature of small teams. Small teams have short communication paths. These shortened communication paths are like nuts on the road, making the journey to the destination easier. We are always trying to reach our destination as quickly as possible, and refuse to hesitate and delay.
This article is an excerpt from “Creative Choice: Product Thinking in Apple’s Golden Age,” by Ken Cochinda, translated by Jia Yongmin, November 2019 edition of CITIC Publishing House.
About the author
Ken Kocienda (Ken Kocienda)
Apple Jobs Times Chief Software Engineer for iPhone.
The chief iPhone engineer of Apple’s Golden Age, has worked at Apple for more than 15 years and participated in the development process of Safari browser and iPhone, iPad, iWatch and other product software. He graduated from Yale University and now lives in San Jose, California.
After going through several startups in the Internet era, he joined Apple’s software team. He participated in the Safari browser browser and used for iPhone, iPad, Software development process for products like iWatch.