直至今日，我仍清晰地記得那一刻我手中溼冷的感覺，史蒂夫向大家鄭重宣布：蘋果已經開發了自己的網絡瀏覽器。一瞬間，我們的超級秘密——這個開發周期長達18個月的項目——成了眾所周知的事情。史蒂夫向大家宣布，Safari加載網頁的速度比IE瀏覽器快了不只一點兒，而是整整三倍。
賈伯斯要的是速度更快
有消息從管理層傳出來，史蒂夫·賈伯斯已經決定了他評判我們瀏覽器項目的標準，其關鍵點只有一個：速度。史蒂夫希望我們的瀏覽器速度快，從網際網路上加載網頁的速度要足夠快，必須遠遠超過Mac計算機上默認使用的微軟IE瀏覽器才可以，因為我們的瀏覽器存在的目的就是完全替換IE瀏覽器。在蘋果，我們總是試著提供開箱即用的最好的產品，除了速度這個方面，我們還需要為瀏覽器提供一整套功能，其中，出色的書籤管理、精簡的用戶界面這兩項在開發清單上佔據了最重要的位置。不過我們的團隊在當下還是把重心放在提高速度這一目標上。上述挑戰給了我們明確的目標。
速度也是史蒂夫對未來網際網路發展趨勢的洞察的一部分，史蒂夫希望我們的瀏覽器能夠做好準備迎接即將到來的浪潮。
要保證速度必須放棄軟體的部分優化即便在程式設計師群體裡，能稱得上著名計算機科學家的人也很少，不過高德納絕對擔得起這個頭銜。下面是他關於優化的言論：程式設計師在思考或擔憂程序裡非關鍵部分的速度上浪費了大量時間，實際上如果把調試和維護考慮進來，這些提升效率的努力實際上有非常強的負面作用。我們應該放棄微不足道的效率提升，在97%的情況下，過早的優化往往是錯誤的根源。我們來看一下這個例子。假設我邀請你到我家的廚房做示範，我讓你：
從冰箱裡拿一罐芥末。
你會很容易地完成這項任務，因為我的廚房儲備了這種調味品。很顯然，執行這句指令會比執行下面這句長度相當的指令更省時：
去超市買一罐芥末。
由於一些指令中包含了更複雜的命令，這些指令的執行時間比其他指令的執行時間更長。這與優化有什麼關係？下面這些是完成其他廚房任務所需要的指令：
把冰箱裡的所有東西都取出來。
把所有物品都放在櫃檯上。
通過增加一個指令來對其進行優化：
把冰箱裡的所有東西都取出來。
把所有物品都放在櫃檯上。
用最少的往返次數完成任務。
第三個指令提出了執行該項任務關於速度的建議。將冰箱和櫃檯之間的往返次數視為約束條件，我們可以合理地認為，如果往返次數減少，那麼整個操作流程可以更快地完成。這種方式正確嗎？上述優化路徑會引起以下問題。如果一次性拿取和卸載大量物品，這種方式可能有效，但事實真是這樣的嗎？如果我嘗試把裝芥末和蛋黃醬的罐子、裝牛奶的紙箱、黃油棒以及盛有昨晚剩菜的盤子放在一起一次性搬運，一旦有東西掉了怎麼辦？這就造成了故障，不是嗎？如果我灑了或者打碎了什麼東西，我是不是要花時間打掃乾淨，才能保證任務「完成」？如果我回頭仔細思考「用最少的往返次數完成任務」這句指令到底指的是什麼，我可能還會認為任務的目標就是使冰箱到櫃檯之間的往返次數最少——但是這是真實的意圖嗎？我不知道，這只是我最好的猜測。實際上我並沒有足夠的信息來確認這項任務的目的。
這個情景告訴我們為什麼像高德納這樣經驗豐富的程式設計師會發出對優化的警告。有時，在瀏覽器開發過程中，即使我們擁有最好的調查結果和「創新性思維」也是不夠的。很多時候我們會發現，在不影響速度的前提下，我們根本找不到增加功能的方法。沒有哪種優化是簡單的，也並非總是充滿樂趣的。
Safari：大家都喜歡的名字
隨著項目發布日的臨近，蘋果的市場部開始著手為我們的瀏覽器取名字。，在此之前的一個月，我們一直將其稱為「網絡瀏覽器」或「亞歷山大」（Alexander），亞歷山大會讓人們聯想到馬其頓國王——一位著名的「徵服者」（Konqueror）。我們認為Konqueror這個名字很討巧，但是它不能作為面向消費者的名字出現在蘋果產品的身上。
史蒂夫·賈伯斯想到了一些名字，當第一次聽到它們時，我哭了。最開始，史蒂夫喜歡「閃電」（Thunder），但很快他喜歡上了「自由」（Freedom）。我覺得兩個名字都很糟糕，我無法想像我告訴人們「我在為自由工作」這一場景，這聽起來好像我是那種漫畫書裡面想成為超級英雄的人。
最終，斯科特提出了一個可行的名字：Safari。這個單詞傳達了一種「環遊世界」的感覺，就如同其他知名瀏覽器——Navigator（航海家）、Explorer（探險家）、Konqueror（徵服者）——帶給人們的感覺一樣，但Safari又絕不是它們的盲從者，是令人耳目一新的。唐也很喜歡這個名字，當然最重要的是，史蒂夫也很喜歡。Safari是我發布的第一個蘋果產品。
在後來的日子裡，我對史蒂夫如何準備這種重磅產品的發布會有了更多了解。在演講開始前的三周或一個月，史蒂夫就開始在蘋果公司的場地裡結合幻燈片進行練習，地點通常是無限循環總部的禮堂。隨著日復一日的練習，他按照他想在主題演講中展示的方式逐步完善這個演講。
這是史蒂夫成為成功演講者的重要秘訣之一。他反覆練習，一遍又一遍地打磨，直到他覺得自己的演講足夠精彩。
我仍清晰地記得那一刻我手中溼冷的感覺，史蒂夫向大家鄭重宣布：蘋果已經開發了自己的網絡瀏覽器。一瞬間，我們的超級秘密——這個開發周期長達18個月的項目——成了眾所周知的事情。史蒂夫向大家宣布，Safari加載網頁的速度比IE瀏覽器快了不只一點兒，而是整整三倍。
史蒂夫展示完Safari圖標後，點擊了下一張幻燈片，上面只有一個單詞：Why（為什麼）？史蒂夫認為十分有必要向大家解釋，蘋果為什麼要推出自己的瀏覽器，他把「速度」作為解釋的重中之重。有些人可能認為推出Safari瀏覽器的舉動僅僅是一種營銷手段，是把產品裡恰好表現出眾的功能當作賣點。
對於任何一種複雜工作，確定清晰的願景和自己要做的事都是解決問題的開始。儘管確定這樣的願景是很困難的，但毫無疑問，完成整個工作更加困難。
你需要想出解決問題的辦法，提出實現構想的計劃，然後高標準地完成計劃，不陷入困境，也不改變努力方向或徹底失敗。最令人緊張和不安的可能是你的辦法、語言以及願景沒有一個好的開始，即便你全力以赴，它們也不會帶領你走向成功。
在瀏覽器項目開始的初期，史蒂夫告訴我們他想讓瀏覽器的速度足夠快。唐給我們制定了實現這個目標的規則：永遠不做任何讓瀏覽器變慢的改動。
此外，PLT使我們有了實現目標的方法。瀏覽器團隊將PLT嵌入了日常工作流程，我們利用測試結果來衡量和監測我們的進度。差不多一年後，當我們做好發布Safari的準備時，史蒂夫可以在舞臺上，用非常直接的方式，告訴全世界我們成功了。
在宣布測試版本之前，我們的Safari團隊僅有10人負責編輯代碼，iPhone的949專利上列出的發明者只有25人。兩個團隊都不是具有幾百名或者幾千名開發人員的軟體團隊。從史蒂夫開始，公司自上而下隱藏了一個實用的管理哲學。
我們的領導想要得到高質量的結果，他們設置了各種各樣的規則，包括管理者要與工作在一線、親自製作示例程序的員工直接交流等。這個要求限制了團隊人數，並且產生了更深層次的影響，我們的開發團隊必須要求每位成員都足夠優秀且有團隊凝聚力。
這些因素十分重要，因為它們可以使人們始終保持足夠的動力，而這正是超大型團隊的主管一直努力的方向。溝通效率高則是小型團隊與生俱來的另一個難得的特點。小型團隊的溝通路徑短，這些被縮短的溝通路徑就好像路上的堅果，使得通往目的地的旅途更加輕鬆。我們總是在努力儘可能快地到達目的地，拒絕猶豫和拖延。