"軟件工程"是指我們在學(xué)校中學(xué)習(xí)的那些理論，經(jīng)過多年的開發(fā)實踐和技術(shù)交流中，我們不斷在對傳統(tǒng)的軟件工程理論進行反思。在將軟件開發(fā)分為3個階段（需求分析、設(shè)計和編程）時，我們很自然地會提出一個問題，"軟件開發(fā)者應(yīng)該繼續(xù)提高專業(yè)化程度嗎？"畢竟，勞動的分工是工業(yè)革命的基礎(chǔ)。正是由于將制造業(yè)分解成多個精確定義的小任務(wù)，一組工人的生產(chǎn)率才能得到突飛猛進。所以，我們想當(dāng)然地認(rèn)為：對于軟件開發(fā)，這種"專業(yè)化"的方式也將同樣有效。

　　這看起來顯而易見，不是嗎？讓一些人成為專業(yè)的分析師，專門獲取和記錄用戶的需求；讓一些人成為設(shè)計師，負(fù)責(zé)從需求文檔制造出設(shè)計規(guī)格文檔；程序員則負(fù)責(zé)根據(jù)設(shè)計規(guī)格進行編碼。很顯然，這應(yīng)該是一種更加高效的工作方式，不是嗎？答案是否定的。

　　問題的分析

　　1. 忽略了溝通的成本

　　同一件任務(wù)被切分而成的小步驟越多，人與人之間傳遞信息所耗費的時間總量就越多。因此，在不需要大量交流工作中（例如制造業(yè)中的很多體力勞動）中，流水式生產(chǎn)線能夠運轉(zhuǎn)得很好；但在需要大量交流的腦力勞動（尤其是軟件開發(fā)）中，這種方式一敗涂地。

　　軟件開發(fā)的絕大部分工作都是在團隊成員的頭腦中完成的。如果要強迫每個人專門從事某一項特定的工作，那么任何一個簡單的項目都會需要傳遞更多額外的中間產(chǎn)品。每一次的傳遞都可能帶來潛在的錯誤和缺陷，因此，每次傳遞都是相當(dāng)昂貴的。沒錯，如果要求每個人都編寫大量的文檔，以降低其他人作出錯誤理解或假設(shè)的風(fēng)險，我們當(dāng)然可以將"由于交流而出錯"的可能性降到最低。但是，"編寫更多文檔"的工作量同樣也是計算在項目的開銷中的。正如Fred Brooks所指出的，如果決定某項任務(wù)成敗的因素是項目組成員之間的交流效率，那么加入更多的人就只會延緩項目的進展。

　　當(dāng)同一個開發(fā)者對需求、設(shè)計和源代碼都有著深入的理解時，軟件開發(fā)就能夠獲得最好的效果。Steven Levy所采訪的所有黑客都是獨自進行設(shè)計和編碼的。在對"影響了（個人）計算機產(chǎn)業(yè)的19個程序員"的采訪中，Susan Lammers也提到了同樣的現(xiàn)象。在這些偉大的程序員中，沒有任何一個使用過軟件工程風(fēng)格的分工方式，他們通常都是獨自深入整個設(shè)計和編碼工作。很有趣的是，他們幾乎每個人都有自己獨特的工作風(fēng)格。

　　2. 導(dǎo)致混亂

　　將傳統(tǒng)的勞動分工強加于軟件開發(fā)，結(jié)果是導(dǎo)致分析師、設(shè)計師、程序員、測試員、用戶界面專家、文檔工程師、技術(shù)支持工程師之間不斷地傳遞信息。過多的交流極大地降低了效率，項目被不斷拖延。任何一點變化出現(xiàn)時，都必須將信息沿整條開發(fā)鏈傳遞下去，并導(dǎo)致一片混亂。項目結(jié)束后不久，軟件就變成了"遺留系統(tǒng)"，因為沒人清楚它究竟時如何工作的。

　　軟件工程對技術(shù)進行人為的細(xì)分，結(jié)果導(dǎo)致任何一個人都不可能了解整個應(yīng)用程序。軟件工程解決這個問題的辦法不是再開發(fā)者之間進行交叉培訓(xùn)，讓他們了解全局，而是不斷強調(diào)文檔的神話－良好的文檔能讓任何人理解整個應(yīng)用程序。不幸的是，盡管文檔能夠很好地記錄軟件中的抉擇和協(xié)議，但卻無法有效地保留、傳遞關(guān)于具體問題的詳細(xì)信息，而這些具體細(xì)微的知識才是最重要的。

　　軟件工程的另一個貽害是：它把文檔搞得聲名狼藉。很多項目實際上根本沒有任何文檔，因為年輕的開發(fā)者們本能地拒斥這種"軟件工程的產(chǎn)物"。

　　3. 缺乏科學(xué)量化的手段

　　"科學(xué)管理"用科學(xué)取代了經(jīng)驗法則。在"科學(xué)管理"的方法中，數(shù)字支配一切。如果要改進什么東西，你首先必須對它進行度量。如果什么東西不能被度量，就不可能對它進行改進。管理者知道一切。任何工作都必然有一條最佳途徑。

　　所以，看到軟件工程師發(fā)明了許許多多軟件開發(fā)的度量方法，我們也就不會覺得太驚奇了。甚至，由"科學(xué)管理"帶來的"時間－動作研究"（time-and-motion study）已經(jīng)被用于研究軟件的使用情況了。在某些特定的問題上，人們已經(jīng)規(guī)定出一些定量法則，例如將光標(biāo)移動到按鈕上需要多長時間（Fitts 法則）、在概率相當(dāng)?shù)男袨橹g作出選擇需要多長時間（Hick法則）等等。

　　在對量化管理的狂熱之中，人們常常忽視了機械活動與智力活動之間的差異。Fitts法則主要時針對機械活動的－盡管移動鼠標(biāo)、點擊按鈕的動作需要眼睛和手的協(xié)調(diào)，但它仍然只是一個（比較復(fù)雜的）機械活動。Hick法則則試圖度量人大腦中的活動。這正是軟件工程犯下的一個經(jīng)典錯誤：它認(rèn)為能夠度量的東西時最重要的，但情況并非如此。

　　從根本上來說，軟件開發(fā)還是一項智力活動。打字的速度從來不是、也永遠(yuǎn)不可能是軟件開發(fā)的瓶頸。要談?wù)撘豁椫橇顒?，唯一的方式就是通過不精確的討論，因為你能度量的東西對于提升效率根本無濟于事。軟件工程之所以有害，因為它忽視了開發(fā)者之間討論的價值－而那是我們理解軟件開發(fā)、提高開發(fā)效率的唯一途徑。

　　軟件工廠總是表現(xiàn)出一種傾向：它們試圖模仿制造業(yè)從前的模式。但是，就連制造業(yè)也在不斷發(fā)展?，F(xiàn)在，哪怕是最熱衷于生產(chǎn)線的人也早已不再談?wù)?quot;完全集成的制造業(yè)"了。如今，汽車企業(yè)不再擁有鋼鐵工廠、煤礦和橡膠種植園。他們不再自己制造輪胎，而是向擅長制造輪胎的企業(yè)購買輪胎。對于軟件組件，道理也是一樣：借助于唾手可得的組件，小型團隊也可以開發(fā)出優(yōu)秀的軟件。

　　"軟件工廠"的概念沒有真正流行，因為軟件的制造實在太容易了。如何與用戶協(xié)作、交流，創(chuàng)建一個良好的設(shè)計，并使其不斷演進發(fā)展，這才是軟件業(yè)中真正的難題。

　　忠告

　　如果你的項目擁有實際上無限的資源，那么軟件工程就是一條有效的軟件開發(fā)途徑。但是，如果你的資源有限，如果你養(yǎng)不起數(shù)百名軟件工程師，請及時放棄軟件工程。你必須認(rèn)識到：軟件開發(fā)更多地是一項智力的、社會性的工作，而非機械性的工作。認(rèn)識到這一點之后，你將可以從軟件工程中學(xué)到有用的東西。