資料來源：黑暗執行緒
Phil Haack寫了一篇探討開發人員產能差異的好文章。可能是因為自己瘋狂熱愛Coding，一直以來對許多客戶、專案經理、公司主管貶低開發人員價值的錯誤認知頗不以為然，於是，這類的文章讀來格外心有戚戚焉。
對開發人員的種種誤解中，我最痛恨的是以下幾種:
1) 為什麼寫一個線上購物網站要花五十萬? 我小姨子的同事唸高中的兒子說給他五萬元就可以搞一個!
2) 每年多少資管畢業生呀? 程式開發人員去街上抓就一大把，還怕找不到人?
3) 不過就寫程式唄! 找誰來寫還不都一樣? 你專案不是缺人，為什麼不叫隔壁組現在沒事的老王加入你的Team? (Darkthread定律: 連砸了三個案子的人，在撐著不離職前都會很涼)
4) 當黑手寫程式有什麼前途? 把系統分析做好，外包給老印、老中的Programmer才是王道! 別把時間花在這種低層次的工作上，你要學習如何成長....
取得Phil的同意，我翻譯了原文並加上自己的詮釋，提供大家參考。
在人月神話(The Mythical Man-Month)一書中，Fred Brooks點出了程式師好壞所造成的產能差異，足以讓許多人跌破眼鏡。
Programming
managers have long recognized wide productivity variations between good
programmers and poor ones. But the actual measured magnitudes have
astounded all of us. In one of their studies, Sackman, Erickson, and
Grant were measuring performance of a group of experienced programmers. Within
just this group the ratios between the best and worst performances
averaged about 10:1 on productivity measurements and an amazing 5:1 on
program speed and space measurements!
依據Sackman, Erickson, Grant對一群資深程式師進行的績效評量研究，最好與最差程式人員的產能差了10倍，在程式速度與空間上則相差有5倍之多。
Robert Glass在Facts and Fallacies of Software Engineering一書中，引用研究報告，提出更驚人的工作績效差異。
The best programmers are up to 28 times better than the worst programmers,
according to “individual differences” research. Given that their pay is
never commensurate, they are the biggest bargains in the software
field.
依據個別差異研究，最好的程式師會比最爛的好上28倍，所以薪水篤定是被低估的，算得上是軟體業裡超划算的便宜貨。
換句話說，優秀的開發人員通常薪水是偏低的，而鳥鳥的開發人員則多領了不該領的錢。(譯註: 手爛掉 手爛掉 手爛掉...)
等
一下，先別急著去拿離職單!
產能與薪水本來就不是呈現1:1的比例，薪水是依個人為公司帶來的價值及貢獻而定，而產能只是所謂"價值"中的一部分而已(雖然它佔了最大的比重)。話雖
如此，我們還是衷心期盼產能上的明顯差異可以回饋到薪水上，但總是事與願違，為什麼?
因為經理人始終無法接受生產力好壞差異這麼大的事實，無論它已被許多研究重覆驗證過。他們的信仰堅定，可不會這麼容易被小小的事實所動搖，更何況放棄信仰豈不稱了無神論者的意? (哈!)
好，不開玩笑了。為什產能差異的事實如此難被接受? 謮容我代公司主管發言:
一個開發人員再怎麼厲害，寫程式的速度也不可能比另一個開發人員快28倍吧?
這是在評量開發人員產能時常見的謬誤! 開發產能不該用程式行數來衡量。無法完成工作的程式寫再多，終究還是不具任何生產力的垃圾。要衡量開發人員產能高低，實際上有很多指標可用，它們都基於一個主要原則(在此借用財務學的名詞)---TCO。
TCO - Total Cost Of Ownership，因持有而付出的總成本
一般來說，我一向只僱用我能找到最好的開發人員，但也不是沒有看走眼過。是的，連我也會出鎚。
想起在前公司有個開發人員，我將一個案子交給這位前同事接手，幾天過去了，沒有聽到任何消息，心想: 很好，事情應該很順利!
又幾天過去了，我晃到他座位旁去關心一下進度，他老兄居然跟我說，他搞不太懂其中幾項需求，原來這陣子的時間全都在"搞懂需求"這件事上空轉。
好的開發人員可以獨當一面，不用你掛心
這點出了好的開發人員比一般開發人員生產力高的主要原因之一---他們可以獨立掌握一個專案的進行。遇到需求不明的狀況，好的開發者會主動找到有權力決定需求的User，設法由他身上擠出答案來，絕不會因為需求不明而白白浪費一個星期的時間。
相同地，好的開發人員也不需要你時時盯著他的進度，反正遇到因難時，他會主動向你或其他同事尋求解決方案。
如果開發人員只是程式寫得快，卻沒有能力主動掌握專案的進行，生產力勢必高不到哪裡去。因為他會佔用你的時間，這部分也得算在他的成本上，要是你月領數十萬，成本就可觀囉。
好的開發人員程式Bug少
我曾經跟經一個老板大力稱讚的"程式快手"一起工作。呼! 他寫程式的速度可真快，製造Bug的速度也很嚇人 orz... 程式碼則亂得一塌糊塗，難以閱讀。
在老板對他的生產力衡量裡，QA部門重製錯誤(Reproduce Bug)及其他程式人員幫他修Bug所耗費的時間顯然被忽略了。不然這傢伙應該叫程式殺手，而非程式快手。
許多人只關心"完成"程式的時間，但這並不是程式全部的成本! 程式開發工作不該在開發者說"寫好了!"那一刻就停止計時，而應該要等到QA部門同意放行後，你才可以按下碼表上的停止鈕。
如我所說，生產力講求的不只是速度，而是效率，意指"迅速地達成目標"才算數。速度再快，方向錯了，充其實也只是在跑心酸的罷了。(譯註: 中國人有句成語一針見血---南轅北轍!)
好的開發人員會寫容易維護的Code
跟減少Bug一樣重要的是Code要力求易讀易懂、利於維護。當Code在螢幕上出現的那一刻起，就算是在維護Code了。
當開發人員要新增或修改系統功能時，艱澀難讀且難以修改的Code會浪費可觀的時間。好的開發人員藉由寫出易於維護的Code，讓隨後接手的其他團隊成員可以少幾根白頭髮，系統變更也可以更快被完成。換句話說，其他開發人員的產能在無形中也提升了!!
好的開發人員Do More With Less Code
好的開發人員另一項難能可貴之處是他總知道"何時不必寫Code"。我的一個朋友說得好:
"寫不如買，買不如借，借不如偷"
除了少數的例外狀況，"非我發明"症候群(NIH，Not Invented Here)
是很可怕的生產力殺手。我曾看過開發者開始著手寫一套自己的Form Validation Framework(譯註: 靠!
我也寫過，但是在ASP時代，所以毋需自責，哈)，直到我提醒他ASP.NET本身就有內建的Validation後才做罷。(雖然ASP.NET內建的
功能並不怎麼樣，但至少會比那位盤古先生寫的來得好)
所有重新發明輪子的舉動都是徒勞無功，因為早已有人幫你把程式寫好了。在大多數的情況下，目標專一的人通常會有較好的表現；遇到類似的情況，借重現有的Library，對生產力的提升效果應該會讓你大吃一驚。
不過，要提醒大家小心一些延展性及彈性欠佳的3rd Party Library，尤其是針對一些很專門的用途，選錯Libary，可能得耗費難以想像的時間在客製化上，猶如橫柴入灶，得不償失。
就
算找不到合適的Library得DIY，好的開發人員也能用較少的Code(但是無損於可讀性)完成更多的功能。例如，要由一個複雜的字串擷取出特定的部
分，菜鳥會傻傻地寫個數百行程式去彈性判斷各種字元排列組合，而識途老馬則會用Regular
Expression兩三行搞定。(對，有人會說RegEx的語法跟天書差不多，但我想學會它總還是比在數百行的SubString、IndexOf中找
頭緒來得容易多；更何況把它學好，可以應用的地方的多得很，絕對超值!)
譯註: 菜鳥程式師們想要"轉大人"嗎? 想學.NET Regular Expression可參考這篇文章。
回到TCO
以上所說的這些特性，都讓好的開發人員具有較低的TCO。不要被Ownership這個字所迷惑，這裡強調的是成本(Cost)，對公司來說就是付出的薪水。
好的開發人員可以用較少的Code完成更多的功能，寫出的程式不但Bug少也容易閱讀及維護，大幅減輕了QA部門、其他同事及管理者的工作負擔，無形中增加了每個人的生產力，這是為什麼產量會差上28倍最重要的原因。
希望這番剖析可以說服管理者，好的開發人員真的具有如研究報告中所說的超高生產力，另外一方面，跟老板要求加薪28倍的任務，就留給各位讀者當作課後練習。
文章定位：
