程式設計師，就像詩人一樣，幾乎僅僅工作在單純的思考中。程式設計師憑空運用自己的想象，來建造自己的「城堡」。很少有這樣的介質——創造的方式如此靈活，如此得益於精煉和重建，如此得容易實現概念上的設想。
這句話是《人月神話》中我比較喜歡的一句話。所謂焦油坑，就是由於如同詩人一般的程式設計師們不斷的將工作推倒重做導致的。正是因為憑空的想象居多，導致軟體產品概念設計不夠完整，從而使得推倒重做之後的體系結構越發龐大，最終導致軟體開發人員怎麼掙扎也窺探不到真正解決問題的方案。
《人月神話》一文中的核心觀點是「向進度落後的專案中增加人手，只會使進度更加落後。」這也是著名的brooks法則，而這句話也充分反映了作者對於人月觀念的觀點，即，人月的觀念是不可靠的，人力和時間在專案工作中並不是絕對的可交換關係，增加人手在軟體開發的工作中並不一定能加快進度。因為軟體的開發工作中，新人的加入往往需要專案的培訓，新人的融入也需要時間，新成員和老成員的溝通，新成員對專案的了解，都需要時間，而人月的觀念則未把這些時間計算在內，所以說，盲目的增加人手，不僅不會加快專案進度，還很有可能會拖慢進度，越多的新人加入，就意味著越多老成員分心指導新人入手專案。那麼如何才能使得專案進度不落後呢？答案是，制定合理的專案進度。
在制定合理的專案進度上，需要對以下幾個方面進行分析：
1、1/3計畫
2、1/6編碼
3、1/4構建測試和早期系統測試
4、1/4系統測試，所有的構建已完成
可以看到，測試的時間佔據了專案總進度的1/2，而在我自己的團隊中，大部分時間則用來編碼，這也是我們需要改進的地方。
外科手術隊伍一章對團隊成員的經驗和質量給出乙個重要的度量：最好的和最差的表現在生產率上平均為10:1，在執行速度和空間上具有5:1的驚人差異！簡言之，$20,000/年的程式設計師的生產率可能是￥10,000/年程式設計師的10倍。也就是說，如果團隊中的成員大部分都是有經驗的程式設計師，那麼其他成員可以喝喝咖啡靜候佳音了（典型的外科手術模式：乙個主刀醫師）。由此也可以看到，軟體公司大概需要什麼樣的人才了。
「也就是說，同每個成員擷取問題某個部分的做法相反，由乙個人來進行問題的分解，其他人給予他所需要的支援，以提高效率和生產力。」這個說法完全推翻了我以前的認知，之前我一直以為乙個團隊需要聆聽每個成員的意見或建議（雖然我們團隊並沒有這樣做），但是讀過這一篇文章以後，發現有時候平等並不是最好的選擇，因為每個團隊成員的能力、智力都不相同，外科手術式的隊伍以及解決方案有時候更適合軟體的開發，即由主要的團隊成員來決定專案中的大部分內容，其他成員給出相應的意見或建議，並輔助主程式設計師完成相應的工作。
我們的團隊模式就類似這種模式，就我自己的體驗來說，總體團隊內部不會出現什麼分歧，一人領導多人輔助其實更加適合敏捷開發，但是我們的團隊主要程式設計師還是少了一些，導致開發人員的壓力太大，任務太重，解決辦法就是將ui編碼等工作交給輔助開發的人員，而主程式設計師負責邏輯處理的編碼部分，這樣就能極大的分擔主程式設計師的壓力，在任務分配上也不會顯得有人無事可做或者說純打醬油。
《人月神話》讀書筆記
p8,程式設計的快樂在於它不僅滿足了我們內心深處進行創造的渴望，而且還喚醒了每個人內心的情感。p19,用人月作為衡量一項工作的規模是乙個危險和帶有欺騙性的神話。因為它暗示人員數量和時間是可以相互替換的。人數和時間的互換僅僅適用於以下情況 某個任務可以分解參與人員，並且他們之間不需要相互交流。p23,...
人月神話讀書筆記
人數和時間的互換僅僅適用於以下情況 某個任務可以分解給參與人員，並且他們之間不需要相互的交流。當任務由於次序上的限制不能分解時，人手的新增對進度沒有幫助。溝通所增加的負擔由兩個部分組成，培訓和相互的交流。相互之間交流的情況更糟一些。如果任務的每個部分必須分別和其他部分單獨協作，則工作量按照n n 1...
《人月神話》讀書筆記
外科手術隊伍 對於軟體開發來說，軟體開發隊伍的選擇往往是乙個難題。在我們的時間課程的當中，每個人都希望可以抱大牛的大腿，因為乙個熟練且經驗豐富的大牛可以抵得上十個新手，如果乙個小隊當中都是如此的大牛，那麼這個小隊可以稱之為當之無愧的精英小隊。對於大型的專案，小而美的團隊往往有些力不從心，精英也不可能...