人月神話的英文是 《man-month mythical》，人月其實是軟體工程管理工程量的單位，乙個人每月的工作量，其實是想說明是使用人月的方式來估算大型專案是不靠譜的，只是乙個神話的方式。而作者frederick p.brooks,brooks被認為是「ibm 360系統之父」，他擔任了360系統的專案經理，以及360作業系統專案設計階段的經理。憑藉在上述專案的傑出貢獻，他、bob evans和erich bloch在2023年榮獲了美國國家技術獎。早期，brooks曾擔任ibm stretch和harvest計算機的體系結構師。
開篇以焦油坑引出，焦油坑，讓陷入其中的猛獸越掙扎越是難以掙脫束縛，陷入坑底。而大型的系統開發就是這樣的焦油坑，各種問題糾結在一起，讓人越陷越深，沒有辦法看清事情的本質。在其中，不要做乙個純粹的樂觀者。《人月神話》中什麼是人月？是使用的在估計和進度安排中的工作量單位。作者認為用人月作為 衡量一項工作的規模是乙個危險和帶有欺騙性的神話。它暗示著人員數量和時間是可以相互 替換的。 人數和時間的互換僅僅適用於以下情況：某個任務可以分解給參與人員，並且他們之 間不需要相互的交流。
「孕育乙個生命需要十月懷胎，所以不管有多少個母親，時間都是一樣的」，闡明增加人手來彌補專案被拖延的進度，有時候是不現實的。從這裡開始慢慢透漏出，人月是神話的韻味。
保持設計的概念完整。無論對小軟體還是大軟體，都必須由乙個設計師主導，最多兩個人討論來共同完成軟體的整體設計。作為乙個軟體，乙個系統，必須有乙個清晰明確的概念模型。具體的實現人員可以細化概念，
很少有人類的活動要力求完美，程式卻像是神的咒語，以乙個個音節、乙個個停頓層層構建出前所未有或已經存在的事物。
但只有總設計者才有否定與發展基本概念的權力。需要注意的一點是，即使是總設計師一直是同乙個人，他腦海中所認為理所當然的規則或者概念，很可能由於沒有明確的文件化，而沒有成為所有開發者共同的概念。在其他開發者編碼的時候，就可能會生成與概念相牴觸的東西，導致整體結構的惡化。這個時候總設計師一定要即時發現，做出更正。這就是外科手術式的開發隊伍。
團隊不是一擁而上，而是以外科手術方式來操刀。
打個比方就像乙個主治醫師操刀對問題進行分解，而其他成員提供各種支援。主導手術的碼農就這樣成長為傳奇中的人物。
想想此書成熟的年代，那些靠敲組合語言，在狹小的螢幕，紙帶儲存，小的可憐的記憶體完成複雜工作的前輩。
想想那些動輒就是議論重新設計語言，實現編譯器的前輩。而如今有了各種各樣的工具，如今的我們站在前輩們的肩膀上。
作者風淡雲輕的寫此書。堪稱舉重若輕。
現代程式設計師的軟硬體工具更加強大，有更多的樂趣，比以前更少的苦惱和麻煩。
實在應該珍惜。
讀《人月神話》
翻開扉頁，購書日期 2003.2.10。實在汗顏，且此類書，我的案頭還有許多。在兩周中抽出時間，翻看完了這本傳說中的經典。總的感覺，收穫並不多，雖說有些東西並未能完全理解，但大多在作者看來是未來的東西，已早成為現實。大致看來，沒有什麼新的概念。於是，也談不上讀後感，只是把看的過程中的筆記重新寫一遍，...
讀《人月神話》
為什麼中國的程式設計師總是在不斷學習新的開發工具 鑽研程式 而不能逐步提公升自己的視野 思維和經驗？摘自序 所謂人月 man month 是軟體開發中工作量的度量，然而它卻不是線性的，10個人10個月可以完成的工作，很多情況下100個人並不能在1個月完成。以下是我的理解與摘抄 斜體是摘抄 當人數增多...
2015 4 25 讀人月神話筆記
趁著這段時間還能抽出些時間，我對前一段時間在專案裡的經歷做了很大程度的思考，不得不說前端時間在專案組裡的猶如噩夢一般，詭異的後端架構 不穩定的 實現 緊張的專案進度以及不斷的需求變更都將開發推導了噩夢的邊緣。對比這些專案經歷，我重讀了人與神話這部描寫360os系統的建造者的經驗輯錄。比較令我震驚的一...