程式人產能之謎

 在程式人的產能差異上，你可能聽過不少的傳說，像是「程式人間有5:1或10:1產能差距並不是種曲解」、「90%程式碼是由10%程式人撰寫」、「優秀軟體開發者價值遠勝平庸開發者10,000倍」等，產能差異在哪？單純關注個別程式人的正向產能，是對的嗎？

產能評量的迷思
Joel Spolsky、Robert C. Martin、Bill Gates分別對產能差異提出了以上的想法，Steve McConnell在〈10x Software Development〉中亦提到「許多研究發現，產能與品質在個體甚至團隊間會有10:1的差異」，總之，任何10次方的產能差距你可能都有聽過，作為管理者，大多會關心如何評量開發者產能，期待促進專案整體的生產力。

只是要量測程式人的產能相當困難，程式設計是個知識工作，先不論其本身有許多難以量化元素，如果為了評量開發者產能，訂出了許多量化指標，就會出現許多收集點數的荒謬行為。那麼，這些10次方產能差距的結論到底從何而來？Joel Spolsky是研究學生用相同技術做相同作業花費的時間，以及取得的作業分數，Steve McConnell研究中談到的是創建、除錯一個程式需要的時間，以及程式的大小、速度、找到的錯誤等。

從收集而來的資料看來，產能差距似乎指向時間與品質，因而有人試圖從中建立指標，期待於每年、每季甚至每月，提前並切割地評量程式人的產能表現，然而實務上不會讓兩個開發者做相同的任務，Tom Cargill也說過：「前90%程式碼耗掉了90%開發時間，剩下的10%需要另外90%的開發時間」，這說明了提前與切割地進行產能評量也是個問題。

從管理角度來看，不可否認地需要某些指標來評量開發者好壞，其實當我們覺得某開發者極具生產力時，實際上，心中確實為他建立了一些指標，也許是類似功能另一開發者花了一整月開發而他只花一星期，某問題另一開發者花了一星期無法除錯，而他接手僅花一天就順心解決……那麼，原因呢？與其就結果來論斷他是否有生產力，不如進一步探究為何他擁有這樣的生產力。

程式人的三種美德
在《Programming Perl》中，Larry Wall鼓勵程式人應培養三種美德：「懶惰（Laziness）、沒耐性（Impatience）與驕傲（Hubris）」。懶惰就會讓程式人努力減少整體工作量，寫一些能節省人力的程式，並寫下這個程式的文件，免得要親自回答許多問題；沒耐性的程式人無法忍受電腦怠惰，寫的程式就會儘可能讓它閒不下來，而不是停下來等待你的需求，驕傲的程式人會寫下旁人無可挑剔，而本身極度自豪的程式。

這三種美德看來就對應了先前談到程式人產能差距指向的時間與品質，探討程式人生產力祕訣的《The Productive Programmer》書籍前言中，也談到即使沒有直接提到這三個名詞，然而這三種美德將會在該書中擴展開來。

程式人的三種美德可以拆開來看，也可以合併來看。想要減少整體工作量有個簡單方式，就是不做重複的工作，電腦絕對比你擅長重複工作，只要告訴它怎麼做，如果發現常常用滑鼠在電腦上重複地走來走去，那就想辦法用工具或寫程式把這個過程「錄」下來，如果發現經常要輸入相同的指令，那就想辦法用工具或寫程式讓這個過程自動化，如果發現類似專案間有些個別差異而增加了溝通麻煩，那就讓它們標準化，實際上會發現，不少現成工具就是這麼創造出來的，是否能瞭解、善用甚至創造出這類工具，就決定了優秀與平庸程式人間的產能差距。

重複的程式碼也是一種重複的工作，無論形成重複的原因是否來自程式碼的剪貼，重複會造成程式碼後續維護時整體工作量的增加，將明顯或三次以上的程式碼重複加以適當重構，透過適當設計讓程式有彈性，就構成了程式人第三種美德。實際上，許多文件、書籍在教導或傳承的就是這三種美德，作為一個進取的程式人，多半會關心如何彌補自身與優秀開發者的這段差距，以提升自我程度為自豪。

程式人的三種罪行

「90%程式碼是由10%程式人撰寫」是Bob大叔在〈One per Pixel〉文章中談到的，文中後續還講了「其他90%的人寫了剩下10%程式（而10%的那些人還得修正這些程式）」，他提到優秀的程式人其實不多，只有10%或許太誇張，也許是20%，也許是30%。實際上在職場生態中確實如此，程式設計對許多人來說，只是份工作，追求優秀與產能這種事，大多數人並不關心。

懶惰、沒耐性與驕傲是程式人的三種美德，這是幽默地從正面意義去看待這三個負面詞語，如果用負面方向來解釋這三個詞語，就是不少從事程式設計工作者的三種罪行。

就懶惰這方面來說，大多數從事程式設計工作的人，就真的只是懶，他們懶得去熟練語言與工具、懶得去探究問題發生的原因，也沒耐性去學習新的東西、沒耐性寫下文件，對於程式本身不會有責任感，程式能動就好，不會去管程式碼的重複、不在意程式的溝通性，甚至隱藏程式碼中的錯誤，隨意地在不同元件中自私地進行各式程式碼侵入，他們建立自己的舒適區，如果你基於改善程式品質的立場去冒犯了他們，他們還會有各式傲慢的回應。

無論是文件或書籍總愛討論如何提升程式人產能，實際上優秀的程式人會自動追求這類自我提升，在關注產能之時，也許不該去評量這類程式人的產能，指標對這類程式人經常是種傷害；真正該注意的是，如何評量出「負產能」，負產能程式工作者建立出來的程式，後續還得耗費優秀程式人來修正，一正一負之下雙方產能抵消歸零也就算了，優秀程式人如果因此心生委屈而離開了，負產能與優秀程式人間的差距，就不是10,000倍可以比擬了。

David Parnas在有次訪談中被問到「軟體工程中最常被忽略的風險是什麼？」他的回答是「不適任的程式工作者（Incompetent programmer）」，並談到「差勁的程式工作者，一年可以輕易創造兩個新工作」，這跟Bob大叔說的類似，因為還得有人來為不適任程式工作者寫的程式進行善後，技術債（Technical debt）這名詞似乎很適合拿來形容這類情況，只不過欠下技術債的是不適任程式工作者，卻得由優秀程式人來償還。

給程式人專注的環境
產能這方面有個人因素，實際上也有環境因素，在關注個別程式人產能之時，別忽略了給予程式人可以專注的環境。

在《Peopleware: Productive Projects and Teams》一書中，就指出：「管理者的工作並不是叫人去工作，而是創造讓人想去工作的情境」。許多公司都會有類似的情況……規範員工每日的產能指標，然後實際上每天不斷地把員工從工作情境中拉離（電話、郵件、開會……），最後在每月、每季或每年考核時，再來指責程式人為何產能如此之差，打擾者也許不只是管理者，不適任程式工作者也經常會做這種事。

關注正向產能當然是好事，只不過程式設計這領域，沒有真正適用的評量，任何基於自我想像的指標傷害性就更大了，不適任程式工作者為了符合指標，也總是能「下有對策」；與其關注程式人的產能，不如關注優秀程式人用了哪些方法提高產能，讓他們能發揮，並且留意不適任程式工作者的行為。

更重要的是得留意，產能差異的謎團也許不只是來自程式人，也有可能是環境或本身，想想看，算過自己打電話打擾其他開發者的次數嗎？這類的指標，也許是從沒有被考量進去的！