我認識的許多軟體工程師，跟我一樣，對於管理『人』這件事，總是有點抗拒。另一方面， 就我個人的經驗中，軟體工程師的開發工作之中，也含有許多管理的哲學。換言之，軟體工程師往往也身為經理人而不自知，只是他們管理的不是『活生生的人』，而是『軟體開發的知識』。以下可以舉幾個例子來說明:

函數命名原則與功能性分權

Common Lisp 裡，很常見的兩個函數，一個是 CAR ，一個是 CDR 。CAR 是 copy address register 的縮寫。 CDR 是 copy decrement register 的縮寫。這兩個函數，在 Clojure 裡，被改成了 first 和 rest 。

哪一個命名比較好呢?我想大家心裡的答案應該都跟我一樣，是 first 和 rest 比較好。CAR 與 CDR 的命名，它描述的是「實作」(implementation )，而 Common Lisp 語言在 1980 年代的 fist 函數的實作，確實就是 copy address register 。另一方面， first 與 rest 的命名描述的則是「目的」(purpose)。

上述的這個命名概念，我幾乎天天在使用。有趣的是，這個概念，在管理學中，也非常重要。 在管理學中，組織常見的一種分權方式是功能性分權。然而，所謂功能性分權，並不是把有會計專長的人編成一個團隊、把有寫程式專長的人編成一個團隊。功能性分權的重點在於功能，這個功能是指該團隊對於企業提供的功能，也就是它對於企業的目的。有趣的地方是，功能性分權常常被誤解、誤用。如同總是有人喜歡用實作來命名函數一樣，總是可以看到某些公司會把有相同專長的員工編成團隊，並且認為自己做了很好的功能性分權。正確的功能性分權，首先要從企業出發，思考企業需要哪些功能性的組織，然後為該特定的功能編組團隊來達成這個功能。

過早的最佳化 (premature optimization) 與策略引導組織架構

『過早的最佳化是一切罪惡的泉源』是軟體工程的名句，這個概念可以應用在軟體開發的許多層面。比方說，開發系統時，一開始只做 back-of-the-envelope calculation 來估計系統的承載量，而不是邊開發就邊做效能最佳化。先用相對高階、抽象的方式開發系統，等到系統開發完成之後， 量測效能瓶頸之後，才對特定的區塊做最佳化。如果我們用正面的表達法來重述這個句子， 那就是:「先釐清楚目標，之後對於實作做最佳化」或是更有哲學意味一點的，「問正確的問題，先於尋找正確的答案。」

企業在發展的過程之中，為了實現企業的策略，必須設計合適的組織架構來達成企業策略。 然而，由於時間會不停地前進，昨天有效的策略，明日可能就會過時。當企業因為外界環境發生變動，需要調整策略時，正確的作法是:『也要對組織架構做適度的調整，因為組織架構是為了達成策略。』而不幸的是，由於種種的原因，許許多多的企業也未能及時調整組織架構， 所以正確的策略往往只能有低效能的執行。過時的組織架構，猶如軟體之中過早的最佳化， 傷害了企業的目標。

讓它崩潰 (let it crash) 與創新紀律

在 Erlang 語言裡，對於例外狀況的處理，是簡單乾脆的一句話:『讓它崩潰』。(註: Erlang 語言的設計，因為語言天生內建了進程 (process)、消息傳遞 (message passing)、進程排程 (process scheduling)、內存管理 (memory management) 種種作業系統的特性，所以可以使用這種方式來編程。) 語言有了這種特性，並且搭配 Erlang 特有的編程方式，外在世界的種種奇怪的狀況，包含「網路不通、網路延遲、硬碟壞了、CPU 壞了」，Erlang 建構的系統， 都有機會可以在系統不需要人工重啟的前提條件之下，自動從錯誤之中恢復。

企業的運作，也是不停地面對現實世界的挑戰。企業如果沒有領先的知識，就不能創造客戶、 創造獲利。能夠長時間領先，唯一的方式就是要不停地創新 (innovation)。而彼得．杜拉克的創新七紀律裡的第一紀律與第二紀律，就是要求經理人從「意外的失敗或是成功」、「不一致的狀況」尋求創新的機會。上述的兩個創新紀律，可以說是如同「從錯誤中恢復」。

有創新紀律的企業，猶如用 Erlang 打造的系統，對於意外的事件、錯誤，視為這是自然且必然會發生的事。Erlang 的設計者認為，要把錯誤處理這種非功能性特性 (non-functional property) 內建到程式語言之中，工程師才容易打造出高度可用、高度容錯的系統。有創新紀律的企業，也把創新內建到公司的價值體系裡，對於錯誤、失敗，不加以掩蓋，並且進一步地尋找創新的機會，如此才能不停地自我更新，有效地回應外界變化的挑戰。

我個人在理解了軟體工程師也同樣承擔經理人的職責，也同樣應用了管理學之後，與自己的主管與同事的溝通，都容易了許多。這個變容易可以說是必然的，管理學的詞彙總是比較大眾化、容易理解。也祝福各位軟體工程師可以溝通順利!