FrederickP.Brooks.Jr.的這本書是我們從事IT的人都應該讀讀的書，雖然做軟件隨著歷史變得越來越專業，但是對于從事軟件編寫的我們來說，歷史會交給我們技巧的演變。
Brooks之前的《人月神話》我還沒有讀，不過透過一些簡介，以及《設計原本》描述的細節不難推測出《人月神話》是一本教導IT如何高效率的編寫出高質量的代碼并且能夠滿足用戶的要求。
做為IBM出身的大牛，在一個巨型公司工作了幾乎半輩子，他身上會或多或少的沾染上大公司的通病。但是這不影響他在設計硬件和軟件方面的權威。時代在發展，軟件開發也從個人到團隊到小團隊的演變，但是一些共通的比如設計，會一直如影隨行。對我們設計人員來說，最希望的就是一旦設計確定，就不會在變動了。但是在現實生活中這是不可能的。有客戶的關系，有設計公司領導的關系，有設計人員的關系，有實施人員的關系，甚至一個掃地的阿姨都能改變設計的正確方向。這在作者的理解是要設計一個理性模型，但是這個理性模型可能有很多約束，包括已知的和未知的。這個理性模型有長處也有缺點。它可以有明確的分工，細致的設計，能夠很好的預測軟件的開發時間和消耗。但是需求是不斷變化的。對于現在的我來說，需求基本上變動不大，約束明確，結果明確，我在項目中可以事先設計好功能的實現。滿足Brooks的開發完整性就好。對于優美的軟件，Brooks提到優美的框架是設計的目標和實現后的結果是一致的，并且附帶代碼簡潔、功能明確的優點。
Brooks對與團隊的協作，以及分布式的團隊協作有深入探討，畢竟在IBM做一個項目需要世界不同地點，不同時區的同事共通努力，團隊協作是歷史發展的產物，功能越來越龐大，需求越來越細化，都決定了大部分的開發者不能精通各個方面，每個細節都有相應領域的執牛耳者，這就決定了團隊協作越來越重要。愛迪生可以一人發明很多東西，現在建造一架飛機需要各個團隊成員通力合作。對于分布式的團隊開發，Brooks提到了各種溝通手段，但是Brooks還是極力推薦團隊成員面對面的溝通，這帶來的結果不僅僅是技術和問題的交流更加流暢。對于文檔書寫，Brooks也是相當在意的。Brooks覺得好的文檔書寫是優美架構的一部分。在我們公司的開發理念就是，盡量把時間用到設計與開發上。我覺得和公司的規模，以及人員流動也有關系。這種現象在現在的小公司或許非常普遍。這也許是未來的一種趨勢。[我覺得未來的公司都是越來越細化，應該是一個小而精的時代]。但是協作確實我們必要的。
Brooks非常重視人才的培養，Brooks再說中說過，他在IBM做過最正確的事就是把一位同事送到高校深造，而這位同事開發出的關系數據庫一直到現在還是IBM的搖錢樹。人才的培養不僅是培養他人，也包含培養自己，我們可以從以前優秀的設計中吸取精華，研習來提高自己的設計。而這恰恰是現在每個從事IT的設計人員所欠缺的。我們在設計建筑時，會去教堂，會去設計優美的建筑參觀。去研究他的歷史，他的架構，他的施工。對于軟件開發，我們也需要這樣的培訓。
設計是預先思考的解決方法，他的優雅或臃腫，他的可擴展或固定。都是我們在設計時的經驗總結。Brooks對于優秀的設計師是通過設計經驗而取得進步還是生而就為設計堅定的選擇了經驗決定。經驗是我們在設計過程中實實在在的碰到了問題并解決了，我們為什么使用這種方法而舍棄另外的方法都是我們在當時的約束以及當時的資源決定的。
