有些比較大型、而且有規劃要進行客製銷售的專案，它在程式工程上有幾個階段，首先是「確立技術可行性」，然後是「提出核心模組」，接著就是開始組成工程團隊開始「應用模組陸續完成大型專案」。

既然有工程團隊，自然不只一個工程師...領頭的工程師自然是跟隨著專案團隊從「確立技術可行性」到「提出核心模組」步驟的那一位。
這樣的工程師往往經過人資精挑細選，具有「最資深」「做過最多東西」「懂很多平台技術/工具技巧」的特質。
專案前兩個步驟在他手中會進行的似乎非常順利，看著用核心模組做出來的雛形，專案領導者（和大老闆們）會開始構思著（幻想著）專案步上軌道後美好的畫面.......

然後專案（工程品質）就垮了。

怎麼垮的？
對不懂技術的人來說，他們可能永遠看不懂這個問題的全貌，就冒然下結論「一定是後續擴增的團隊成員資格不符、能力不佳」。然後他們的解決方案可能是拉著那位核心工程師（可能加個薪、給個頭銜跟大辦公桌）要求這人一肩扛下重組工程團隊的任務.......

然後專案（工程品質）就死了。

（有些時候，「為了拯救專案而做的事情，才是真正害死專案的癥結。」有機會再深入討論。）

事實上，這位工程師往往就是問題的癥結。
因為這位工程師根本不懂「怎麼用平行的心態去跟別人合作」。
講直白一點，「他在一開始用自己設計的核心模組做出雛形，但不表示這套核心模組可以交給其他工程師去進行其他專案。」

為什麼？
因為「設計核心模組」其實是門很抽象的、非技術性的學問，（就跟「如何讓專案具有可維護性」一樣，）但這位工程師正好只懂技術、正好只懂完成自己眼前看到的問題，給他越多權限、或越明確的認知「別人要跟隨你的腳步做事」，他針對問題所完成的解決方案就越不可用。

聽起來有點不可思議，可能同時違反了大家的經驗與直覺。
用個直接的例子來說明吧......

這位工程師有天寫了個函數A，為的是完成某項工程。

functionA(var a){
.......
}

但過了幾天幾個禮拜後，可能是工程內容改變，所以需要擴增函數A的內容，或是大家發現Bug，所以要進行修改並釋出新的函數。
不管怎樣，這其實都是很常見的事情。
結果大家會看到這位工程師針對函數A進行了以下的修改。

functionA(var a, var b){
........(完全沒有針對當「b」無傳入時設計該做什麼事情，就是真的只負責「擴充功能」「修正Bug」)
}

…………

沒翻桌的人大概都不懂技術或不懂如何團隊合作編寫程式。

函數A可能已經釋出在多個專案裡使用了，而且每個專案都不只使用一次。
（我經歷過最慘的例子是「每次點擊任何功能」都會呼叫到這個函數A。）
忽然改寫函數A的結構與使用方式，等於要專案工程師把已經完成的功能都修改過，甚至連已經通過測試的功能也要將測試結果作廢。

有點經驗或認知的工程師會將函數A這樣進行修改........

functionA1(var a, var b){
........
}

functionA(var a){
var b = ....(初始化)
functionA1(a, b);
}

工程師會另外釋出新版的函數A1，然後在函數A中呼叫函數A1，避免使用到函數A的地方都要進行大規模改寫。

修改核心模組時不去想辦法避免專案工程師要進行大規模改寫，專案工程師往往就要自我毀滅式的加班。
如果連續發生這種事情，專案工程師的體力就會開始往下掉、工程品質與效率也會跟著往下掉，而且是惡性循環的幅度。

（這是很多Android專案垮掉的原因。因為Google的Android工程師們顯然不懂這個道理。）

順便一提。
這技巧看起來很簡單，但真的很多工程師都不會。
而且是那些越積極吸收新技術、技術年會場場跑、各種新穎工具都能快速上手的工程師，往往不具備這些技巧。

很諷刺的是：他們很多是知道這個問題存在的。
只是因為沒人在針對這些技巧舉辦年會，各種技術平台或工具平台往往也只專注在「SDK說明」或「工具使用技術說明」，所以這些工程師可能年資十年，但從不涉獵這方面的技巧....
（可能也遭遇過不只一次，但他們選擇跟其他人一樣把責任歸咎給其他工程師，或是認為「這世界上一定有可以完美解決這個問題的工具」，然後轉頭去跳近無窮無盡的工具One Piece中...）

「喔！不就是彼德原理的活生生例子嘛～」不懂什麼是彼德原理？保重。