超混「幽靈工程師」正啃食科技巨頭！全球每年浪費900 億美元

雖然覺得只是老生常談的標題黨新瓶舊酒，畢竟與本行相關，仍然拜讀一番。因為懶得找原文，以下發言純屬個人見解。

首先，軟體工程師「生產力」差異果然很大，可以溯及這個行業伊始。其實需要技能的工作多少有此現象，有人借用所謂 80/20 法則，說 80% 的工作是由 20% 的人完成。軟體業也許稍微極端一點，達到 90/10，接近這篇報導提到的數字，只是倒過來看。「幽靈工程師」儘管難聽，卻真實存在；倘若的確毫無貢獻，自然應屬汰除之列。

文中的生產力分析模型，屬於軟體工程範疇，目的在提升品質，而「人」是品質的重要環節。不過乍看之下大為懷疑，因為提及一堆業界巨頭，套用這個模型，每年要損失多少多少個億云云。我的第一個疑問是，咦，這些公司會願意提供程式碼給他分析嗎？

答案綜合新聞頭尾，原來是「來自數百家公司超過 5 萬名工程師的 Java 程式碼」，猜想是 Java 比較易於反組譯進行分析吧！如此必定有取樣偏差，因為很多系統核心大量採用 C/C++ 或其他編譯語言，而這部份是公司資產、智慧財產權，等閒不會給人看。隨便拿那個百分比，直接套在微軟、估狗頭上，恐怕只是因為他們市值高，算出來的金額嚇人罷了。

至於文中提到的幾個生產力指標，恰好落入幾年前我的舊文「程式匠雜談一二」裡頭，「如何替軟體工程師打考績」一段提到的迷思。我覺得一篇軟體工程的論文，眼界應該不止於此，多半是寫新聞或做簡報的人，特意挑些淺顯易懂的例子，吸引眼球而已。

像是「每月只更新程式碼不到三次」、「僅進行微不足道的修改，例如編輯一行或一個字元」，其實要看實際效果如何。以我自己常做的抓蟲診斷為例，有時候花上幾天功夫找毛病，又花上幾天功夫實驗不同對策並評估優劣，最終解決方案，可能真的只改一行而已。然而效能翻倍，而過程中寫下的幾百行「假設工程」，卻只能自己收藏，不會放進正式產品。要是照更新次數或幅度打考績，我大概也算「幽靈工程師」了。

總之，其結論或許若合符節，但模型本身有可精進之處，而實際運作，應該也不只新聞提到的那幾點。

說俺「貪吃工程師」倒沒問題😁