軟體工程瀑布模型的出現是軟體工程成熟的標誌。在此之後人們又從實際工程中提煉出了很多的模型。例如現在都被人們稱道的rad
模型，螺旋模型以及
rup模型。模型的出現給了人們乙個參考的標準。然而事實證明就只是照著模型的樣子就可以做出客戶心目中的產品這是不現實的。對於不同的人來說理解的不一致性，分工的不同，做完工程的每乙個階段，並不等於做工程。工程不是過程的累加，不是這麼隨隨便便就能成功的。做過程不是做工程的精義，也不是目的。
程式設計中實現才是目的。工程只是實現的手段。小到乙個稱手的工具，大到乙個幾千萬的專案，實現才是目的。前人沒有工程的概念，也照樣做出了產品。他們關心的是怎麼實現這個問題，客戶的要求是什麼樣的。而現在我們有了工程，卻放錯了關注的焦點，我們把重心放在了工程要怎麼做，工程要求怎麼做上，然而結果卻是工程完成了，過程的每一步都完成了，然而卻沒有實現每乙個目標。
為了工程而工程，讓我們迷失了自己。我們關心的是怎麼把工程圖畫的更完美一點而不是花時間考慮客戶的要求工程的目標。在溝通中，我們也是走過場。每個部門都按照自己的想法描述了工程的情況，而沒有論及任何事關客戶意圖的事情，就像演戲一樣，一切都完成了，一遍遍的排練，只是過場的話，將會是無休止的演出，最後也將會是以專案的失敗告終。
模型用的好，將是軟體行業對客戶的福利。瀑布模型描述了開發的主要環節，後來一群人把這些環節捏來捏去或反覆疊加，就成了rad,rup
以及其他的未知模型。應用的好的當屬被稱為「日本
it工業開發史的活字典」的
v模型。
在日本近年來老齡化嚴重，因此勞動力短缺導致的勞動輸入和專案外包，直接影響了它的組織管理模式。因此根據實際問題的需要，v
模型應運而生。模型的左端是外包給的團隊或公司，右端則是日本企業軟體中有豐富經驗的工程人員。這樣既節省人力，又可以保障工程質量。那麼根據我們實際情況的需要，瀑布模型是不是也可以為我們所用，將它改變成勳章模型，煙斗模型呢？答案是肯定的。當我們做完工程後，回頭反思一下，是不是我們的工程裡也蘊含著寶藏般的經驗呢？或許你會有著驚人的發現。
學習要學其精髓。學一些實實在在的東西。越是簡單的東西，往往越接近本質。學習瀑布模型，可思過程的本質，學習rup
不成只剩一些文件模版可抄。如果懂得模型都可以換做最原始的瀑布模型，而文件的書寫卻可以是
xp或者
rup，你還會去選擇架子上的東西麼？
工程不是做出來的。工程需要組織。專案經理行駛好角色，讓每個人都有適合的工作去完成，並把大家都聯絡在一起。工程擇日就完工。
大道至簡 失敗也是積累
沒有人的一生是一帆風順的，甚至可以說沒有任何東西是一帆風順的。小樹經歷風雨才能長成參天大樹，毛毛蟲只有破繭才能成蝶，就算是鑽石也要經過打磨才能綻放璀璨的光彩。這些失敗不是成功路上的絆腳石，他們只是要減緩你邁向成功的步伐，教你學會欣賞沿途的風光。不能論是失敗也好，挫折也罷，都會成為你人生路上的財富，是...
讀《大道至簡》第五章「失敗的過程也是過程 」有感
大道至簡 講述了軟體工作者如何思考的問題，失敗的過程也是過程 就講述了軟體工程師在做專案甚至是工程時應該拿出一種總樣的態度和行為來實現它。做過程不是做工程 講述了軟體工程自提出以來的一些進步 軟體工程的瀑布模型，瀑布模型將軟體開發的過程分成需求 分析 設計 開發和測試等 5 個主要階段 以及這些進步...
《大道至簡》之溝通
c語言是每個程式設計師必需學習的語言，也是必須要掌握的語言。它對於開發人員，卻不一定對每乙個人來說重要。客戶是不需要掌握 c語言的，在開發人員看來，他們希望客戶學習或精通 c語言，這樣可以方便他們之間交流和溝通，可是要求客戶學習 c語言明顯是自殺式的行為。所以，開發人員最還不要只見面對客戶，讓專案經...