開發者生產力/代碼質量與經驗無關？！
你知道嗎，我們從來沒有發現一個開發人員多年的經驗與他的代碼質量或生產力之間有直接關系。
關于開發人員經驗與生產力關系的研究
最初對于個人編程生產力的研究是在 1968 年進行的，在這之后的 30 年間，其他研究人員至少做過 8 次同樣的研究，結果并沒有什么不同。他們在研究了一些平均有 7 年開發經驗的專業開發人員后統計出：
- 開始編碼時間比率約 20 : 1
- 調試時間比率約 25 : 1
- 程序執行速度比率約 10 : 1
- 程序大小比率為5：1
他們發現沒有一個開發人員的多年經驗和代碼質量或生產力之間存在直接聯系。這說明經驗和生產力（即生成代碼的能力）之間不存在相關性，也說明經驗和軟件質量（即最大限度地減少缺陷）之間沒有相關性。
上圖展示了兩個開發人員群體——差的（生產效率、產品質量均低）和優秀的。研究發現，每個群體中都存在開發經驗豐富和貧乏的開發人員。該研究只是說明多年的經驗并不重要，并沒有說明培訓指導是否能幫助開發人員提升。
在不考慮合法性的前提下，這意味公司可以辭退掉擁有多年經驗、工資高但產出低的開發者，并雇用一些沒幾年經驗但高效高質的開發者。
盡管研究存在缺陷，但是仍顯示出好的開發人員和差的開發人員之間存在數量級的差別，而這種差別與經驗無關。關于“開發人員之間存在數量級的差異”已經被其他研究所證實。（見英文原文最后的參考文獻）
技術越來越先進，而開發者不是
你可能會認為與過去相比，現在我們對軟件開發了解得更多，畢竟現在：
- 我們有更好的計算機語言
- 我們有更先進的技術
- 我們有對高效開發模式有更好的研究
- 我們在大學中有正規的軟件專業
上面這些都是事實，但現在開發人員之間仍然存在較大的差異。這意味著有一些X因素驅動著產品開發，X因素可能是開發人員規劃并作出正確決定的能力。
壞消息是，如果你不是一個高效、高質量的開發者，那么僅僅是多年的經驗可能不會令你變得更好。
學會決策
開發人員每一天都面臨著“如何構建自己的代碼”的決策。比如如何：
- 規劃代碼路徑
- 將函數封裝成類
- 將類封裝成包/模塊
開發人員面臨的編碼決策，其中有許多是復雜的，好的開發人員會安排他們的工作，并做出正確的決定。差的開發人員只是“跳過”，他們認為，他們總是可以重寫代碼或在做出決定后再彌補錯誤。差的開發人員甚至沒有意識到他們的決策過程是糟糕的，他們完全可以通過規劃工作來變得更好。
解決方案：可能是 PSP 和 TSP
Watts Humphrey 試圖通過針對個人的 PSP（Personal Software Process，個體軟件過程）和針對團隊的 TSP（Team Software Process，團隊軟件過程）來讓開發人員了解評估、規劃開發和決策的價值。但只有很少的組織接受他。Capers Jones 已經分析了超過 18,000 個項目，發現：
- PSP 可以提高生產力 21.2%，提高質量 31.2%
- TSP 可以提高工作效率 20.9%，提高質量 30.9%
這些研究，對創建開發團隊有一定的幫助。比起擁有平庸開發人員的大型團隊來說，擁有高效開發人員的小型團隊更為合理，因為他們知道如何規劃并作出正確的決定。
PSP 和 TSP 建議：改造一個差的開發人員的最好的方式是教他們如何作出更好的決策。
要知道，隨著時間的推移，知識技能、編寫高效高質代碼的能力是會提升的。
結論
本質上，我們都知道這一點，但只是很難做到。如果公司中的高級管理人員知道這些研究，那么高效高質的開發者會得到更多的報酬，差的開發者可能就需要另謀高就了。這樣做不僅降低了構建軟件的成本，同時也提高了軟件質量。
不幸的是，我們一直都在為各種編程方法、語言和技術辯論、斗爭不已。大多數組織中的開發人員的編碼方式，正在逐步使“巫毒科學（VoodooScience）”看起來像“科學”。（譯者注：指一些不正統的編碼方式逐漸成為主流）。
英文原文：NO Experience Necessary!!!