達到卓越

From The Joel on Software Translation Project

Jump to: navigation, search

達到卓越

譯者:jiing

作者:周思博(Joel Spolsky)

Monday, July 25, 2005

2005三月25日,星期一


約耳談軟體的一部份,http://www.joelonsoftware.com

在二千年的三月,我架了這個站並以有點不可靠的聲明說:「大部份人以為你要有個點子才能建立成功的軟體公司,他們錯了。」:

常見的信念是:當你建立一個軟體公司時,目標是找到一個簡潔的點子能解決某些之前尚未被解決的問題,然後實作它,並賺點錢。我們都稱此為「建立一個較佳的捕鼠陷阱(build-a-better-mousetrap)」的信念。但是軟體公司的真正目標,應該是將資本轉換成可以使用的軟體。

過去五年我已經實際地測試了此理論。我和Michael Pryor於2000年九月開創的公司所用的公式可以被總結為四大步驟:

最佳工作條件 → 最佳程式員 → 最佳軟體 → 利潤!

這是相當合宜的公式,尤其因為我們在開創Fog Creek時的實際目標是去建立一個我們會想要工作的軟體公司。在那些日子裡我曾經聲明:好的工作條件(用誇張的說法就是「建立世上最好的軟體開發人員會想要工作的公司」)會產生利益,就像巧克力導致肥胖,或是電視遊戲裡的卡通性愛會導致黑社會式的濫殺一樣的自然。

不過今日我只想要回答一個問題,因為如果這部份不是真的,我的整個理論會崩解。問題是,談論關於有「最佳的程式員」是否有意義?程式員之間的差異是否大到需要特別在意呢?

rs1.jpg

或許這對我們而言很明顯,不過對許多人而言,這個假設仍需被證明。

數年前,一家較大的公司正考慮買下Fog Creek,而當我一聽到那家公司的CEO說,他不是真的同意我僱用最佳程式員的理論時,就知道這絕不可行。他用了一個聖經的隱喻:「你只需要一個大衛王,和一支只要能遵守秩序的軍隊」。他的公司的股價迅速地從20跌到5元,所以我們不接受那個提議是一件好事,不過這並不能歸咎於對大衛王的盲目崇拜。

習於抄襲的商業記者及大公司都是倚賴收超額報酬的管理顧問,由顧問來幫忙思考甚至咀嚼他們的食物等等。在那個世界中的傳統智慧,似乎把減少程式員的花費視作最重要的事。

在某些其它的工業中,便宜比好更重要。Wal*Mart藉由銷售便宜的產品,而非好產品而變成地球上最大的公司。如果Wal*Mart試著銷售高品質的貨物,他們的花費會上昇,而且他們整個便宜的優勢會喪失。例如如果他們試著銷售一個能禁得起嚴格測試(如在洗衣機一直洗)的短管襪,他們必須使用各種昂貴的元件(比如棉花),於是襪子的單價就會上昇。

那麼,為何軟體產業內沒有低成本供應商(就是儘可能雇用最廉價程式員的人)的空間呢?(提醒我去詢問Quark整個「全部解僱再僱用低薪新人」的計劃是如何進行的。)

這裡是原因:複製軟體是免費的。那代表程式員的花費是分散在你銷售的所有軟體備份之上。就軟體而言,可以增進品質而不會增加每個售出單位的成本。

基本上,設計的附加價值高於它所增加的成本。

或者,概略地說,如果你試著從程式員上省錢,就會做出蹩腳的軟體,而且根本省不到那麼多的錢。

同樣的原理可套用到娛樂產業。雖然布萊德彼特要求很高的薪水,請他來拍你最新的鉅片還是值得的。因為薪水可以由僅因布萊德是這麼紅而去看電影的數百萬人分攤。

或者,換個方式套用它。雖然安潔麗娜裘莉要求很高的薪水,請她來拍你最新的鉅片還是值得的。因為薪水可以由僅因安潔麗娜是這麼紅而去看電影的數百萬人分攤。

不過我尚未證明任何事。「最佳的程式設計師」是什麼意思?不同的程式員所生產的軟體品質真的有如此大的變異嗎?

讓我們以一般古老的生產力來開始吧。要量測程式員的生產力相當困難;幾乎任何你想得到的尺度(除錯的原始碼行數,功能點,命令列引數的數目)對[The_Joel_on_Software_Translation_Project:測量|遊戲本身都毫無意義],而且很難在大型專案上取得具體的資料,因為很少會讓二個程式設計師去做同一件事。

我所倚賴的資料來自耶魯大學教授史丹利.艾聖斯特( Stanley Eisenstat)。每年他會教授一門需要密集編程的課程CS 323,編寫程式佔了課堂作業的很大部份。共約五次的編程作業每個費時約二週。作業對於大學課程而言是非常嚴格的:實作Unix命令列shell,實作ZLW檔的壓縮器,等......。

由於有太多學生問這門課有多少功課要做,以致艾聖斯特教授開始要求學生回報花在每個作業上的時間。他持續了好幾年謹慎地收集這些資料。

我花了一些時間在玩味這些資料:它是我所知道唯一讓數十名學生在相同時間用相同技術做相同作業的資料集。這在進行實驗進行時相當難以控制。

我對這資料做的第一件事是計算十二個作業中的每一個所用時數的平均值、最小值、極大值和標準差。結果如下:

ProjectAvg HrsMin HrsMax HrsStDev Hrs
CMDLINE99 14.84 4.67 29.25 5.82
COMPRESS00 33.83 11.58 77.00 14.51
COMPRESS01 25.78 10.00 48.00 9.96
COMPRESS99 27.47 6.67 69.50 13.62
LEXHIST01 17.39 5.50 39.25 7.39
MAKE01 22.03 8.25 51.50 8.91
MAKE99 22.12 6.77 52.75 10.72
SHELL00 22.98 10.00 38.68 7.17
SHELL01 17.95 6.00 45.00 7.66
SHELL99 20.38 4.50 41.77 7.03
TAR00 12.39 4.00 69.00 10.57
TEX00 21.22 6.00 75.00 12.11
ALL PROJECTS 21.44 4.00 77.00 11.16

你在此注意到最明顯的事是變異很大。最快的學生比平均的學生快三倍或四倍,而比最慢的學生快上十倍。標準差非常之大。於是我想,嗯,或許這些學生正在亂寫作業。我不想含括花費四小時在作業上但卻無法產生一個可運作程式的學生。所以我限縮資料,只含括在第一個四分位(quartile)分數等級...也就是程式碼品質在前百分之二十五的學生。我應該提及在艾聖斯特教授課當中的分數等級是完全客觀的:他們被以程式碼通過多少自動測試的公式化計算,只此而已。編程風格不佳或遲交並沒有扣分。

無論如何,這裡是第一個四分位級的結果:

ProjectAvg HrsMin HrsMax HrsStdDevHrs
CMDLINE99 13.89 8.68 29.25 6.55
COMPRESS00 37.40 23.25 77.00 16.14
COMPRESS01 23.76 15.00 48.00 11.14
COMPRESS99 20.95 6.67 39.17 9.70
LEXHIST01 14.32 7.75 22.00 4.39
MAKE01 22.02 14.50 36.00 6.87
MAKE99 22.54 8.00 50.75 14.80
SHELL00 23.13 18.00 30.50 4.27
SHELL01 16.20 6.00 34.00 8.67
SHELL99 20.98 13.15 32.00 5.77
TAR00 11.96 6.35 18.00 4.09
TEX00 16.58 6.92 30.50 7.32
ALL PROJECTS 20.49 6.00 77.00 10.93

沒有什麼差別!第一四分位的標準差幾乎完全相同。事實上當你仔細地觀察資料,會發現時間與分數間顯然並無可察覺的相關性。下面是其中一個作業的典型散佈圖...我選擇於2001年時指派給學生的作業COMPRESS01,也就是Ziv-Lempel-Welch 壓縮的實作。選擇的原因是因為它的標準差接近於整體的標準差。

HrsVsScore.png

時間對分數的散佈圖

在此沒什麼可以看的,不過那就是重點。工作品質和所花費的時間是沒關係的。

我針對此點詢問艾聖斯特教授,而他指出另一件事:因為作業要在固定時間內交出(通常是半夜),而遲交的懲罰有很大的影響,很多學生在專案完成前便停了。換句話說,部份由於公佈作業和交作業期限間的時數是有限的,所以學生花在這些作業的最長時間有其下限。如果學生有無限的時間來做專案(比較符合工作的世界),散佈值可能只會更高。

This data is not completely scientific. There's probably some cheating. Some students may overreport the time spent on assignments in hopes of gaining some sympathy and getting easier assignments the next time. (Good luck! The assignments in CS 323 are the same today as they were when I took the class in the 1980s.) Other students may underreport because they lost track of time. Still, I don't think it's a stretch to believe this data shows 5:1 or 10:1 productivity differences between programmers.

此資料並不完全是科學的。其中可能有點作弊的成分。某些學生可能會多報寫作業的時間以獲取同情,好在下次獲取較簡單的作業(祝好運!今天CS323的作業和我在1980年代修課時完全相同。)其它的學生可能低報了,因為他們忘了追蹤時間。儘管如此,相信這些資料顯示出程式員間出現5:1或10:1生產力差距,在我看來並不算是種曲解。

不過,等等,還有更多!

如果程式員間的唯一差異是生產力,你可能想說可以用五個平庸的程式員來取代一個真正的好程式員。這顯然是行不通的。原因是Brooks的法則:「對一個延遲的軟體專案增加人力會使它更遲。」一個好的程式員在單一工作上工作並沒有協調或溝通的花費。五個程式員在同一件工作上工作必須協調和溝通。那會花費很多的時間。儘可能使用最小的團隊有額外的效益;人月真的是神話迷思啊

不過,等等,仍還有更多!

用很多平庸的程式設計師而非一群好的程式設計師,真正的問題在於無論他們工作多久,永遠沒法子像偉大程式設計師做得那麼好。

五個Antonio Salieris(譯:電影阿瑪迪斯中害死莫扎特的宮廷樂師)不能譜出莫札特的安魂曲(Mozart's Requiem)。甚或,即使他們工作一百年也一樣。

五個Jim Davis(無聊卡通貓的創造者,其中兩成的笑話是有關於週一有多爛,剩下的是關於貓有喜歡義大利千層麵(lasagna)和那些結尾警語!五個Jim Davis用盡餘生來寫喜劇,也永遠寫不出Seinfeld的納粹湯廚橋段。

The Creative Zen team could spend years refining their ugly iPod knockoffs and never produce as beautiful, satisfying, and elegant a player as the Apple iPod. And they're not going to make a dent in Apple's market share because the magical design talent is just not there. They don't have it.

創巨的Zen團隊即使花費數年美化他們醜陋的iPod仿冒機,也永遠做不出如Apple iPod般漂亮、令人滿意而典雅的播放器。而他們也無法搶到Apple的市場佔有率,因為神奇的設計天才並不在那裡。他們沒有這種人。

平庸者就是永遠達不到天才隨時能唱出的高音。能唱出莫札特午夜皇后(The Queen of the Night)中f6高音的女主唱少得像是快絕跡,而沒有著名的f6就無法演出午夜皇后。

軟體真的與藝術般的高音有關嗎?「或許某方面是吧」你說:「不過我是在醫藥廢棄業寫應收帳款的使用者介面。」說得不錯。不過這裡講的是軟體公司和以收縮膠膜包裝的軟體,而這種公司的成敗直接取決於程式碼的品質。

而且我們在過去的幾年間,已經看過很多偉大軟體的例子,那些真正的高音:平庸的軟體開發者就是做不出來的東西。

回到2003年,Nullsoft推出了新版本的Winamp,在他們的網站有以下的注意事項:

  • 華麗的新外觀!
  • 時髦的新特色!
  • 大部份的東西真的能動!

最後一項「大部份的東西真的能動!」讓每個人笑了,而且他們很快樂並且對Winamp感到很興奮,然後他們親身使用它並告訴朋友,他們認為Winamp真是棒,全都是因為他們真的在他們的網站上寫著「大部份的東西真的能動!」這不是太酷了嗎?

如果你把一堆多餘的程式員丟去Windows Media Player團隊,他們會達到那種高水準嗎?一千年也不會。因為在那個團隊加入愈多人,就愈可能出現一個脾氣真正壞的人,認為在你的網站上寫「大部份的東西真的能動!」既不專業又不成熟。

更別提那個意見了:「Winamp 3:幾乎和Winamp 2一樣新!」

就是那種東西讓我們愛上Winamp。


當美國線上時代華納公司的豬頭插手時,網站上這些有趣的東西就不見了。你可以想像他們就像阿瑪迪斯裡的Salieri一樣憤怒、痛苦地啜泣著,試著打壓所有可能嚇到一位明尼蘇達州的老婦人的創造性象徵,而代價是可能會清除所有能讓人們喜歡上這個產品的事物。

或者看一下iPod吧。你不能換電池。所以當電池壞了,真慘。買個新的iPod吧。事實上如果你將它送回工廠,Apple會換一顆電池,不過這得花$65.95。哦,真他媽貴。

為什麼你不能更換電池呢?

我的理論是,因為Apple很重視他們美麗性感iPod上平滑無縫的完美表面,而那些在其它便宜爛貨上所看到的恐怖電池蓋,那些總是會斷的電池門閂,那些塞滿口袋棉線的縫隙和所有那些噁心東西,都會讓它破壞無遺。iPod是我所見過消費電子產品中最無縫的。它很美。它讓人感到美,就像平滑的河石。而一個電池門閂會讓這整個河石般的效果蕩然全無。

Apple made a decision based on style, in fact, iPod is full of decisions that are based on style. And style is not something that 100 programmers at Microsoft or 200 industrial designers at the inaptly-named Creative are going to be able to achieve, because they don't have Jonathan Ive, and there aren't a heck of a lot of Jonathan Ives floating around.

Apple基於格調做了一個決定,事實上,iPod充滿著基於格調的決策。而格調並不是一百個微軟的程式設師,或是名不符實的創巨(Creative)裡二百個工業設計師所能達成的東西,因為他們沒有Jonathan Ive,而外頭能找到的Jonathan Ive並不多。

我很抱歉,我無法停止討論iPod。那個漂亮的拇指滾輪及它小小的喀嚓聲.......Apple花了額外的錢在iPod上裝一個喇叭,好讓拇指滾輪的喀嚓聲聽起來像是來自拇指滾輪。如果喀嚓聲是由頭戴式耳機來播放,他們就已經省下了好幾分錢...幾分錢!不過拇指滾輪讓你感覺像是由你掌控。人們喜歡掌控的感覺。掌控的感覺讓人們快樂。拇指滾輪平穩流暢地回應,並且對你的命令發出聲音,這種事實會讓你快樂。不像其它6,000種口袋型消費性電子廢物,按下開關時開機要等很久,你必須等一分鐘才知道是否有任何事發生。是你在掌控嗎?誰知道?想想你擁有按開關馬上就能用的行動電話是什麼時候的事了?

風格。

快樂。

感情的吸引力。

這些是在軟體產品和電影中,以及在消費性電子產品中造成大熱門的原因。如果沒有把這些東西做對,你或許可以解決問題,不過產品絕不會變成讓公司裡的每個人致富的頭號產品,也不能讓你們全都可以開著有風格的、快樂而且吸引人的車(像是法拉利Spider F-1),並且仍有足夠的錢去在你自己的後院建造一個嬉皮士群居之會所(ashram)。

這不僅是「十倍多的生產力」的事。它是「一般生產力」的開發人員從未達到,但卻能做出偉大軟體的那種高水準。

令人難過的,這並不真的能套用於非產品性的軟體開發。內部開發的軟體很少會重要到需要僱用巨星。沒人僱用桃莉巴頓(Dolly Parton)在婚禮上唱歌。這是為何令人滿意的職業生涯(如果你是個軟體開發者)大都在真正的軟體公司裡,而不要是某些銀行裡做IT工作。

現在的軟體市場是某種贏家全拿(winner-take-all)的系統。製造MP3播放器的除了Apple外,沒有別人賺錢。除了微軟外,沒有人由試算表或文字處理賺到錢。是的,我知道,他們做了反競爭的事才取得那種地位,不過那不並改變贏家全拿的事實。

成為第二名或是有個「夠好了」的產品都是你無法承受的。它必須是引人注目地好,我的意思是好到讓人們都注目它。從真正、真正、真正天才的軟體開發者得到的贈品獲得非凡卓越的唯一希望(譯:意思是有天才不一定做得到,但是沒有天才是萬萬不能)。以下就是整個計劃:

最佳工作條件 → 最佳程式員 → 最佳軟體 → 利潤!

這些頁面的內容代表個人的意見。

所有內容的版權© 1999-2006 by Joel Spolsky. 保留所有權利。

Personal tools