在軟體工程研究中，被驗證得最多的結論就是對於同等經驗的兩個不同程式設計師，在效率和質量上可能會有10倍的差距。研究人員還發現，這種差距也適用於團隊級別上，也就是說在同一行業內的不同的團隊也是如此。
軟體開發中的個人效率的變化
首先發現不同人在程式設計生產力上的巨大差距的研究，是2023年由sackman、erikson以及grant三個人完成的。他們研究了工作經驗平均在7年的專業程式設計師，並發現最好和最差的程式設計師寫新**的時間比為20∶1；除錯次數是25∶1；程式大小是5∶1；程式的執行效率是10∶1。他們還發現，程式設計師的經驗和**質量或效率並沒有關係。
在詳細地研究了sackman、erickson以及grant的研究結果之後，我們可以發現他們所使用的方法中有很多缺陷，例如把使用低階程式語言和高階程式語言的程式設計師合在一起研究等。但是，即便把這些缺陷考慮進來，他們的資料也仍然表明，最好的程式設計師和最差的程式設計師之間的差距能達到10倍以上。
那次研究之後，還有很多其他關於專業程式設計師的相關研究都證明了乙個結論：程式設計師的水平也分三六九等（具體內容參見本書中的參考文獻）。
除些之外，很多軼事傳聞也支援這種觀點。在20世紀80年代中期，當我還在波音公司工作的時候，有個約80個程式設計師組成的專案組正面臨著無法按時完成一項關鍵任務的風險。這個專案對於波音來說至關重要，所以他們把專案上80個人中的一大半換成了另外1個人，而這位仁兄單槍匹馬地完成了所有的程式設計工作，並按時交付了軟體。我並沒有在這個專案組中工作，也不認識這位天才，但是這個故事是一位我所信任的人告訴我的，所以我相信這是真的。
這種差距並不僅限於軟體行業。norm augustine的乙份研究指出，在各行各業中，包括寫作、橄欖球、發明、警務工作等，都存在乙個情況，那就是行業中位列前20%的頂尖人才的產出佔到了該行業總產出的50%，無論這些產出是得分、專利、偵破的案件還是軟體 。你可以想想看，這還是有道理的。我們都知道，有的學生就是比其他學生優秀，運動員、藝術家甚至家長也是如此。既然這種差別存在於所有人群中，那麼軟體開發又怎麼會例外呢？
巨大的差距帶來的負面影響
augustine的研究發現，由於有些人完全沒有任何實質的貢獻（例如不能得分的前鋒、沒有專利的發明家、無法破案的警探等），人與人之間的差距的實際情況可能比上文提到的資料還要大。
在軟體行業中似乎就是這樣。在多個已發表的關於軟體開發效率的研究專案中，大約有10%的實驗參與者無法完成實驗任務。這些研究報告常常會這樣說道：「所以我們從資料集中排除了這些參與者的結果。」但是在現實生活中，如果某個人「無法完成任務」，你就不能簡單地「從資料集中排除他們的結果」了。你或者得等他們完成，或者得另外指派乙個人完成他們的工作，等等。這裡有乙個有趣（而又可怕）的暗示，那就是在軟體行業中，差不多有10%的人對專案產出的貢獻是負數。
和此前一樣，這也和我們在現實生活中的感受一致。我相信很多人都能夠在共事過的人中找出符合這個描述的人。
什麼造就了真正的「10倍程式設計師」
很多人並不喜歡被貼上「10倍」這樣的標籤，因為他們覺得人們會說：「我們團隊中曾有個超級程式設計師，他牛哄哄的，每個人都不願和他來往，要是沒有他整體效率反而還要高些。」
通常來說，任何對10倍程式設計師的實用定義都必須考慮這樣的程式設計師對於團隊其他人員的影響。我也知道的確有牛哄哄的超級程式設計師。但更多的時候，那些牛哄哄的超級程式設計師其實只是普通水平的一般程式設計師而已，甚至還達不到普通水平。他們只是用牛哄哄的外表來讓自己的表現看上去不那麼差而已。我所共事過的真正的超級程式設計師們除了技術水平以外，通常還有很好的團隊精神（雖然有時也有些例外）。
測量程式設計師的個人生產力的問題
由於很多研究都指出不同程式設計師的效率可以有10倍的差距，導致很多人產生了乙個想法，那就是測量他們在自己組織內的個人效率。無論如何，這種想法所涉及的測量「活的」程式設計師的生產力和一般研究中所說的生產力有很大不同。
軟體工程研究通常用完成某個任務所需的時間、每小時或每個月能寫多少行**或者其他一些標準來測量生產力。但如果你嘗試在商業環境中用這些標準來測量生產力，那就會碰到很多問題。
生產力=每月產出的**行數嗎
軟體設計是一件非確定性的事情，對同樣的乙個問題，不同的設計師/開發人員會做出完全不同的解決方案。如果我們用每月產出的**行數（或者類似的標準）來衡量生產力，那麼我們就預設了用10倍的**來解決同樣的問題的程式設計師就有10倍的生產力。顯然事情並非總是如此。比如某個程式設計師可能會有乙個絕妙的設計想法，結果只用10%的**就解決了普通程式設計師需要100%的**才能解決的問題。
有人曾斷言，偉大的程式設計師寫的**總是更簡短。事實上，程式設計水平和**的簡潔性之間可能有著某種關聯，但我現在並不想做這樣乙個寬泛的結論。我只想說，偉大的程式設計師總是努力把**寫得更清楚，而結果通常就是更簡短的**。不過有時候，最清楚、最簡單和最明顯的設計和那些更「巧妙」的設計相比，需要更多一點的**。在這種情況下，我認為偉大的程式設計師也會用稍微多一點的**來避免太過於取巧的設計。無論怎麼說，用「每月產出**行數」來衡量生產力的想法都是有問題的。
dilbert漫畫中有乙個故事：老闆說每發現乙個bug就獎勵10塊錢，大家都高呼這次賺到了，還有人想通過這個辦法「寫出輛小貨車」來 。故事正好說明了這個問題，即如果你用**的產出量來衡量生產力，有的人就會利用這一點，寫很多很多也許完全沒有必要的**。這裡的問題並不在於「**量」這個標準，而在於舊式的管理思想，即「人們只會做會被考察的事情」。但你必須小心不要考察錯東西。
生產力=功能點嗎
「每個月的**產出」所帶來的問題有一部分可以依靠功能點的標準來衡量程式規模。功能點是一套「合成」的測量程式大小的標準。包括輸入、輸出、查詢、檔案數量等都被考慮進來，作為確定程式大小的引數。低效的設計/程式設計風格並不能產生更多的功能點，所以功能點這個標準不涉及**量的問題。但是它卻有乙個更實際的問題，那就是你需要專業人士來計算功能點（很多公司並無這種人才），而且功能點和個人產出的對應也非常粗略，所以無法用於確定程式設計師的個人生產力。
複雜度呢
管理者常說：「我總是把最困難、最複雜的程式設計任務交給最好的程式設計師去做。所以無論用什麼方法來衡量，他的生產力好像總是比別人低，但是如果同樣的事情讓別人來做，就可能花上兩倍的時間。」這種現象很正常，但是也會影響我們定義和測量生產力的方式。
到底有沒有辦法可以測量個人生產力
前文提到的這些困難讓很多人認為：要想測量個人生產力簡直困難重重，沒人可以做到。但我認為要想正確地測量個人生產力是可能的，只是需要注意以下幾點。
在現實專案中，個人生產力的標準很難找到乙個對專案管理有益而又符合統計學規則的用處。根據我的經驗，除了做研究之外，人們想對個人效率進行測量的動機通常來自一些在統計學上不能成立的結論。也就是說，雖然我知道在研究中對個人效率的測量非常有意義，但是我認為在實際專案中卻很難找到它的合理用處。
軟體開發中的團隊生產力差距
軟體專家們很早就已經發現，團隊生產力的差距和個人生產力的差距一樣大，是以數量級為單位的。這裡有一部分原因是因為物以類聚，人以群分，這一點已經由一次對來自18個組織機構的166個職業程式設計師的研究證明了。
又比如，在一次對7個完全相同的專案的研究中，研究人員發現，在這些團隊中耗費精力最多的是最低的3.4倍，而對於程式的大小，最大的是最小的3倍。雖然生產力有一定差距，但是這次研究中的程式設計師都來自相似的背景。他們都是科班出身的職業程式設計師，而且都有多年的經驗。我們可以合理地推測，如果研究物件的背景差異再大一些，那麼他們之間的差距會更大。早期的乙份對程式設計團隊的研究曾指出，對於同樣的專案，不同團隊所提交的程式大小的比例可以達到5∶1，而所需時間的比例可以達到2.6∶1。
barry boehm等研究人員為了確立cocomo ii 成本估算模型而研究了超過20年的資料，並總結到：對於同樣的程式，能力評分在15+的團隊需要的時間是得分為90+的團隊的3.5倍（以100分算）。如果乙個團隊比另乙個團隊在程式語言或者應用領域上更有經驗，那麼這個差距還會更大。
乙個具體的例子就是lotus 1～2～3第三版和微軟excel 3.0開發團隊之間的生產率差距。兩者都是在1989～1990這個時間段發布的桌面電子**應用程式。由於很少看到兩個公司公布相似專案的資料，所以這種死對頭之間的對比就顯得尤其有趣了。這兩個專案的資料如下：excel的工作人員總共消耗了50個工年 ，共寫了649 000行** [8]。而lotus 1～2～3消耗了260個工年，共寫了400 000行**。excel的團隊每個工年的**產出是13 000行**。而lotus的團隊每個工年的產出只有1500行**。兩個團隊之間的生產力差距超過了8倍，正好證明了我們此前的主張，即團隊的生產力也有差距，並且有著更大量級的差距。
有趣的是，這些量化的結果和局外人對於這些專案的感覺非常貼近。lotus 123第三版當時是出了名的跳票王，比預期的時間至少晚了兩年才發布。而在微軟內部，excel大受讚揚，被譽為是微軟最成功的專案之一。對於真實公司的真實專案，這種程度的同模擬較恐怕已經是能做到的極致了。
如前所述，這個例子說明了造成生產力差距的各種因素。lotus和微軟都煞費苦心地為各自的專案招募了頂級的人才，所以我懷疑團隊生產力的差距並不只是由於團隊成員的能力差距造成的，還牽扯到了很多組織結構上的因素，比如產品遠景是否清楚、客戶需求是否明確以及成員之間是否能同心協力，等等。
組織的因素會影響團隊生產力的發揮。傑出的組織中個人能力平庸的團隊可以超越平庸組織中個人能力傑出的團隊。當然，像傑出的組織+傑出的團隊或者平庸的組織+平庸的團隊這樣的組合也不是沒有的。在這種時候，團隊生產力（或者叫組織生產力）和個人生產力一樣相差10倍也就不足為奇了。
程式設計師程式設計生產力相差10倍意味著什麼？
在軟體工程研究中，被驗證得最多的結論就是對於同等經驗的兩個不同程式設計師，在效率和質量上可能會有10倍的差距。研究人員還發現，這種差距也適用於團隊級別上，也就是說在同一行業內不同的團隊也是如此。軟體開發中個人效率的變化 首先發現不同的人在程式設計生產力上的巨大差距的研究，是1960年由sackman...
程式設計師的生產力
剛剛看到一篇文章，說是好的程式設計師生產力是普通程式設計師的幾倍，甚至上百倍。文章是乙個台灣人寫的 對裡面關於 工具 和 自動化 的描述，有了一些新的領悟，故記錄於此。公司總是在強調，完成本職工作，只是meet，如果想exceed some 或是 exceed most，一定要有創新思維或者積極主動...
程式設計師如何提高生產力，程式設計師如何提高工作效率
分享 我總結的提高程式設計師生產力的方法 被 打斷 是破壞程式設計師生產力的罪魁禍首。程式設計師在被打斷後一般不能做到立刻重新開始程式設計。被打斷之後繼續程式設計通常程式設計師需要重新看一遍 才能進入到程式設計的思維環境中，才能想起來被打斷之前的思維邏輯，再從被打斷的點重新開始。這個過程大概要花 3...