讀完《夢斷程式碼(Dream In Code)》樣書，最後韓磊的譯後記中已經提到了Chandler專案的結局，它失敗了，它成了眾多失敗軟體專案中的一個。這個結局無疑又加重了自己看完這本書後心情的沉重：做軟體真不容易。
今天的軟體專案，已經成為一個錯綜複雜的建築工程，不斷變化的應用環境（包括使用者），使得軟體需求被不斷更新，今天100個需求，明天減10個、改5個、加80個，這在不斷公開發布的升級版開源軟體以及Web網站應用中表現的就頗為明顯。為了滿足這種需求及由此需求所帶來的程式設計及調錯成本，人們已經發明瞭眾多方法，比如一旦專案被人們認為足夠“大”，就用物件導向來代替程式導向，以及使用物件導向所衍生的面向元件—–但所有的這些，面對複雜的外部需求，程式設計師們感到還是遠遠不夠。
《夢斷程式碼》裡同樣在反映這個現實，描述了大量導致軟體專案進展困難的問題。作者無法給出一種靈丹妙藥，甚至沒有表達太多自己對於解決問題的傾向性意見。但其中提到了一種案例是“實用最小主義”：
1）儘量少的人。這意味著溝通成本的降低，意味著更容易較為完整的相互理解彼此的思路，意味著軟體團隊開發中涉及最複雜的因素“人”的問題在理論上的減少。
2）儘量少的時間。這意味著人出於謹慎原則會更青睞於選擇自己最熟悉的解決方案，這裡的解決方案指的是平臺、框架、思路等等。
3）儘量少的功能。這意味著只能選擇最有把握實現且最為貼近根本需求的功能。
大多數軟體工作人員在繼續研究和創造新的方法論，這種“實用最小主義”的論調對他們來說顯然是一個保守以求專案安全的方案，歸根結底，它是在減少問題的理論上限和發生的概率。
我倒願意多考慮一些樂觀的因素，這麼多年來，積累的方法實際上已經大大提高了我們解決問題的能力，類庫和框架越來越龐大的同時也的確在為我們減少問題。“實用最小主義”這樣的條款和“方法論”並不衝突，他們總是在相對的變化，也就是說，隨著方法論的不斷完善擴充，“實用最小主義”的門檻實際上也在不斷提高：今天一個被3名程式設計師認為棘手的功能，可能2年後一個程式設計師獨立就可以輕鬆在某個框架上完成。
《夢斷程式碼》中對軟體工程所面臨的種種困難與艱難的描述，即便再過5年讀也許都不過時。因為正如原作者所說，書中描寫的是一隊人馬並肩扛起程式碼大石，雖歷經磨難仍欲將其推上山頂的故事，而正是這種故事成就著今天全世界億萬臺伺服器和PC機上執行的各種軟體，成就著人類不斷超越實現更偉大的夢想。