做過程不是做工程
軟體工程這個概念被提出的時候大概是在20個世紀60年代末。它作為成熟的概念的標誌是軟體工程的瀑布模型的提出。
瀑布模型將軟體開發的過程分成需求、分析、設計、開發和測試五個主要階段，其主要環節關係表現為如下的這樣一種形態
在瀑布模型之後，很多人開始研究過程模型的問題。很多從實際工程中提煉出來的過程模型都是值得稱道的，例如RAD（Rapid Application Development，快速應用開發）模型、螺旋模型和現在常被提及的RUP（Rational Unified Process，Rational統一開發過程）模型。
模型就是“樣子”。人家拿出一個東西來說：這是模型。其言下之意就是要你按照這個樣子來做。過程被描述為可重複的模型，實施的結果卻可能演變成為相當尷尬的局面，如圖所示。
我們看到，按照模型所描述的這個“樣子”，做完過程的每一個階段，並不等於做完了工程。或者說，工程並不是這樣就可以做成功的。
換而言之，無論是用RAD模型還是RUP模型來做工程，即使是亦步亦趨，也做不好工程。
如果工程可以那樣做成的話，只需要有瀑布模型就足夠了。因此“做過程”並不是做工程的精義。
做過場
前面那張圖就是一個過場。儘管那是一張用來描述“溝通問題”的經典圖例
如果每一遍（或者用RUP的那個術語“迭代”）都只是“過場”的話，專案將只是一場無休止的演出而已。
最終呢？觀眾受不了，就交錢走人；演員受不了，就下臺散夥。戲目和專案的結局，竟如此的相似。
實現，才是目的
很多人把問題的本質給忘掉了。從最開始，從我們程式設計開始，我們的目的就是實現一個東西。無論這個東西是小到稱手的一個工具，還是大到千萬的一個工程，我們的目標，都是要“實現”它。
工程只是一種實現的途徑。最初做開發的前輩們，不用什麼工程或者過程，也一樣編出了程式，也一樣解決了問題，也一樣實現了目的。
工程不是做的，是組織的
不能“做”工程，而是要“組織”工程。專案經理的工作，就是要去組織這個工程中的各個角色，使得分工明確，步調一致，共同地完成這個專案。
大道至簡：軟體工程實踐者的思想 第五章 失敗的過程也是過程