第一章的標題是死定了，描述了面臨大堆DDL的程式設計師的窘態。在軟體開發的世界裡，人們用失速slippage描繪進度更不上計劃的情況。 弗裡德里克布魯克斯在三十年前觀察到：“構建軟體最難之處在於決定說什麼，而不是怎麼說。”我們或許並不能理解而這一論斷，畢竟剛剛接觸軟體工程的我們，還沒有學會如何清晰的說，考慮這些似乎為時過早，但我們能仍要意識到合理規劃時間進度的重要性。

  書中還提到，開源給出了一種生產和分發軟體的替代性經濟基礎方案，它還能徹底改變軟體開發的具體過程，散播到廣大人群中。根本上來講，開源改變了軟體按開發的目的，不再是微軟那樣的為賺取利潤而生產，而是讓程式設計師從中找到樂趣，自我驅動的程式設計師實際上更加高效，即時這本身並沒有經濟利益。瑞蒙德寫道：“樂享即高效”。Github等開源網站也驗證了這一說法。

  在程式設計專案的早期階段，團隊選擇語言和技術，準備接入點時，這個問題初時無關大局，重選亦可，但隨後轉而變得堅如鐵石，關係重大。組合語言離機器很近，隨後的Fortran挑戰了高階語言一定比機器程式碼慢的語言，一次編譯就可以解決，隨後高階語言增出不窮，畢竟晶片的電晶體可以幾年翻倍，人的腦袋可做不到，更加友好的語言顯然會獲得更高的效率,所以卡普爾選擇了Python用於編寫Vista。

  2002年的網路泡沫消失，許多程式設計師轉而投身開源專案，無所事事的程式設計師投入了新的開源工程。專案途中，他們遇到了軟體複用的兩難選擇，建立還是借用。世上到處是別人寫好的程式碼，借用一下難道不是很容易嗎，但同樣有很多程式設計師毋庸置疑的認為，自己能實現更好的程式碼。軟體不像樂高積木，擁有不可分割的最小單元，而軟體有著普遍多樣性，這就如同軟體的烏托邦。但依然有人不斷為之努力，一直到開源式開發和網際網路帶來革命，帶來了Python，Perl，這樣提供了大量程式碼的語言，程式設計師大多選擇了去網上尋找開源的庫，而不是花時間自己實現一個。那麼使用一堆現成的程式碼就完成了軟體嗎？程式設計師們隨後發現，這些拿來的程式碼所做不到的地方，恰恰是與眾不同的創新之處，也是建立這個專案的出發點。