《人月神話》
關於軟件工程方面的書記可謂是多如牛毛，可是有多少是基於實際開發項目抽象而出的呢？很幸運，《人月神話》就是這樣的一本書，真真正正的從實際大型項目中領悟而來，可謂經典二字。《人月神話》一書的內容來自Brooks博士在IBM公司SYSTEM/360家族和OS/360中的項目管理經驗，作者爲人們管理複雜項目提供了最具洞察力的見解，既有很多發人深省的觀點，又有大量軟件工程的實踐。
最近讀完了這本經典，感喟不可不多，無論是從項目的基礎，還是到整個項目的框架集成，都有着不同以往的感悟。
《人月神話》提出了2條著名的法則： 1、人月神話：向一個已經延後的項目中投入更多的人力資源只會讓它更延後。 2、沒有銀彈：沒有一種策略，技術或者技巧可以極大地提高程序員的生產力。
Brooks在書中根據人月的不可互換推導出一個怪論：向進度落後的項目增加人手會導致項目更加落後。這個法則在如今的大型項目管理過程依然是很重要的，然而到今天爲止，還是有大量的編程人員、測試人員、項目經理和軟件公司老闆在錯誤地使用人月 來衡量軟件開發的工作量。關於人月的真實情況應該是：不能用人力換取時間。它的思想恰到好處地應用於文檔項目的管理。有多少次查看文檔項目的經理思考通過增加人手縮短時間表？Brooks說，“導致大量軟件項目進入失控的原因是時間表的缺漏，這比所有其它因素的組合還多。”他給出了幾個原因。首先，Brooks責備可憐的估計技術，它錯誤的“搞亂了前進中的努力。”因爲估計的不確定性，經理們缺少“禮貌的倔強”去支持那些看上去比其它需要更長的時間線的步驟。一旦時間（表）流逝，傾向於加入更多的人力，而這就像“火上澆油”，會導致一個新的災難生成的循環。當然，一個基本的錯誤就是假定人力可以嚴格的和時間交換。Brooks指出，這個公式僅在項目成員不需要和其他人交流的項目中成立，比如：拾棉花。然而，一旦項目中包含連續任務和依賴關係時，可以交換的思想立刻就土崩瓦解了。
那麼關於此，什麼纔是對的。Brooks認爲由一個組織，其結構類似於外科團隊的，由一些專家設計並完成全部項目的核心工作而由另外的人力在特定的途徑上支持他們的努力，來執行產品開發可以治癒上述病症。Brooks說到，這條僅有的路是在一個項目早期完成“概念完整性”的通途。大部分關於這些完整性的重要的表述通過這個規範發生，“那是一本計算機手冊加上性能規範……第一批文檔中的一篇產生計劃中的一個新產品，最後的文檔完成它。”文檔是關鍵，這是重要的。
沒有銀彈，這種說話是不是對的。人狼的傳說可能有人聽過也可能沒聽過，人狼是一種具有人和狼兩種特徵的恐怖生物，而銀彈是消滅它的一種最有效的子彈，如果看過《吸血鬼傳說》也許就能和容易的理解這一點。作者將軟件開發比作人狼，而將提高軟件開發效率的方法比作銀彈。作者預言未來十年，想要試圖通過尋找一種有效地銀彈將軟件開發效率提高一個甚至幾個數量級，這種銀彈不可能出現。沒有銀彈這篇文章裏作者列舉出了當時一些非常先進的技術或思想理念，例如Ada和其他高級編程語言、面向對象編程、人工智能、專家系統、“自動”編程、圖形化編程、程序驗證、環境和工具、工作站等。雖然這些先進技術在一定程度上提高了軟件開發的效率，但是始終沒有達到銀彈的效果。距離作者的預言已經過去有20多年了，縱觀現在的軟件開發領域，雖然新技術層出不窮，但是還是沒有一種銀彈能夠讓軟件開發產生一次革命。
從 實際的效果來看，真正適合讀這本書的人應該是哪些管理者，因爲作者就是從管理者的角度來系統介紹軟件開發生命週期中的大大小小細節。事實大於雄辯，作者以實際的開發的項目經驗來闡述相應的理論，深入淺出。作爲30年的經典，放在今天來看依然有着不小的用處，但是隨着時代的改變，新技術的出現，書中的道理也不是完全的正確。整本書中很注重文檔的作用性，作者認爲一個優質的文檔就是項目成功的保證，這一點與傳統的軟件工程很相似，但是卻與極限編程的觀點相悖。所以，也許作者是想傳達出這樣的一個觀點：授人以魚不如授人以漁。