軟體開發中的管理學 (management science in software development)

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

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


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) 內建到程式語言之中,工程師才容易打造出高度可用、高度容錯的系統。有創新紀律的企業,也把創新內建到公司的價值體系裡,對於錯誤、失敗,不加以掩蓋,並且進一步地尋找創新的機會,如此才能不停地自我更新,有效地回應外界變化的挑戰。

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