概述#

Joel 挑戰一個普遍的錯誤觀念：「必須先有一個好的點子，然後才能開辦一家成功的軟體公司。」他認為開辦軟體公司的真正目的不是「先做好老鼠夾，再抓老鼠」（build-a-better-mousetrap），而是將資本轉化為有用的軟體。

Fog Creek 的核心理念#

2000 年 9 月，Joel 與 Michael Pryor 創辦 Fog Creek 軟體公司，其理念可以總結為四個步驟：

最好的工作條件 → 最好的程式設計師 → 最好的軟體 → 利潤！

本章的核心論點：談論「最好的程式設計師」到底有沒有意義？程式設計師之間的能力差別真的那麼重要嗎？

為什麼不能只雇用便宜的程式設計師？#

軟體的複製成本為零#

• 與製造業不同，軟體的勞動力成本會分攤在所有銷售出去的副本中
• 如果銷售量很大，品質的改進並不會造成單位軟體成本的上升
• 本質上，軟體品質的改進會創造出新價值，而且價值創造的速度要快於成本提升的速度

娛樂業的類比#

• 就像拍電影花錢請 Brad Pitt 主演是值得的——因為他是票房保證，報酬可以分攤到幾百萬觀眾頭上
• 壓低程式設計師工資只會得到品質很垃圾的軟體，而且這實際上不會為你省下很多錢

耶魯大學 CS 323 的數據#

Joel 引用耶魯大學 Stanley Eisenstat 教授的數據來證明程式設計師之間的能力差異：

• 課程包含 12 道程式設計題，每題需要約 2 星期完成
• 資料涵蓋數十個學生在相同條件下完成相同題目的時間

關鍵發現#

• 最快的學生做題速度比普通學生快 3-4 倍，比最慢的學生快 10 倍
• 標準差之大非常驚人
• 即使只看前 25% 的優秀學生，標準差幾乎與整體相同
• 作業的品質與所花費的時間基本上是不相關的

Eisenstat 教授的評分極端客觀——學生交上來的程式碼通過自動測試進行打分，完全不考慮編碼風格、遲交等因素。

不只是生產率的問題#

布魯克斯法則（Brooks’ Law）#

• 向一個已經延誤的軟體項目增加人手，只會使它更加延誤
• 一個優秀的程式設計師獨自完成一項任務，不需要額外的溝通和協調
• 如果讓 5 個程式設計師一起完成同樣的任務，他們之間必須溝通和協調，會花掉大量時間
• 人力與工時的互換是一個神話

質的差別，而非量的差別#

用許多平庸的程式設計師代替少數優秀的程式設計師，真正的問題在於：

• 不管平庸的程式設計師工作多長時間，他們做出來的東西都無法像優秀程式設計師做得那樣好
• 5 個 Antonio Salieri 也寫不出莫扎特的《安魂曲》
• 5 個 Jim Davis 也永遠寫不出 Seinfeld 中 Soup Nazi 那一集的劇本
• Creative 公司的 Zen 播放器團隊即使再花上許多年，也永遠做不出像 iPod 那樣優美的產品

一流的歌唱演員不管在什麼時候，都可以很輕鬆地唱出高音，而平庸的歌唱演員就是永遠做不到這一點。軟體也是如此。

iPod 的啟示：風格與設計的力量#

• 蘋果的每一個決定都出於風格（style）的考慮
• iPod 不允許更換電池，是為了保持無縫的優美外觀
• 拇指轉輪加上輕微的「咔嗒」聲，讓使用者感覺自己在控制中
• 這種風格不是 100 個程式設計師或 200 個工業設計師能堆出來的——需要的是像 Jonathan Ive 這樣的設計天才

贏家通吃的市場#

• 軟體市場有「贏家通吃」（winner-take-all）的味道
• 排名第二或「還不錯」的產品，對你來說就意味著失敗
• 你的產品必須非常優異，而開發優異軟體的唯一希望就是依靠那些真正優秀的軟體天才

整個計畫就是：最好的工作條件 → 最好的程式設計師 → 最好的軟體 → 利潤！ 這不僅僅是「生產率高 10 倍」的問題，而是「普通」程式設計師永遠都唱不出開發優秀軟體所需要的那種高音。