這是人月神話：軟體專案管理之道（20週年紀念版）的第十八章：《人月神話》的主張：是真是假？(Propositions of the Mythical Man-Month: True or False？)，這裡的開場白是這樣的『別管別人懂不懂我們的意思，簡單扼要都非常好』(For brevity is very good, where we are, or are not understood.)，這一章是在跟1975的出版做比較，感覺有點在做總複習吧，如果之前ㄚ琪已經有提到了，我就不再贅述，如果有新鮮的點子，那我就再多說一點好了。
在The Introduction of The Tar Pit這一節裡，ㄚ琪應該要多補充這個行業工作的苦難：
- 將做事態度調整到追求完美，是學習軟體工程的最困難部分
- 由其他人來設定目標，並且必須依靠自己無法控制的事物（特別是程式）；權威不等同於責任
- 實際情況看起來要比這更糟：真正的權力來自於每次工作的完成
- 任何創造性活動都伴隨著枯燥耗時的辛勤工作，建構程式也不例外
- 人們通常期望專案在接近結束時，（bug、工作時間）能進展得快一些，然而軟體專案的情況卻是越接近完成，進展得越慢
- 產品在即將完成時總面臨著陳舊過時的威脅
後面的描述ㄚ琪覺得，還可更加地延伸到我們人所學得軟體技術，也會很快地過時，你若是要投入這一行，持續地追求新知有可能是必要的。
在 The Introduction of The Surgical Team這一節裡，ㄚ琪注意到作者所說的上帝對婚姻的設計，看來兩個人的團隊是最好的組合，神的大智竟然可以應用在軟體工程上，當你在學福音的時候你會注意到這點嗎？
在The Introduction of Why Did the Tower of Babel Fail?這一節裡，有關團隊成員跟工作手冊的關係，『每一位團隊成員都應該看到〔工作手冊〕全步的文件內容』，現在作者改口為『每一位團隊成員都應該可以看到全部的文件內容，也就是說，全球廣域網路(World-Wide Web)的網頁應該可以滿足需要』，那時網路似乎還滿起飛，現在看起來讓作者改口了，這個技術真是讚啊。
另外我忘記提到一個關鍵，持續更新內容，不管是在工作手冊上，或是在網站或部落格上，持續更新是王道，再學習福音上，持守到底才是成功。
David Parnas的一個絕招，『所有人都要看完所有東西的目標真是大錯特錯，有部份應該被封裝(encapsulated)起來才對，不是屬於你的東西，就不必也不被允許去看裡頭的細節，你只應該看到介面』，這一點是作者激推的。
在The Introduction of Ten Pounds in a Five-Pound Sack這裡，ㄚ琪有提過硬體的便宜，作者已經改變暫存區域的使用原則了，看來見解相同。
另外作者提到一個落伍的觀念『程式庫裡的每一個組件都應該包含兩套程式碼，一套是執行速度最快的，一套是使用空間最少的。』之前看起來不覺有什麼不對，但現在有點感覺了。
在The Introduction of The Documentary Hypothesis這節裡，這點『關鍵文件的相當於提供了一個監督和預警的機制。』這點ㄚ琪也漏掉了，補充之。
在The Introduction of The Whole and the Parts這節ㄚ琪漏掉了Vysotsky的話『有太多太多的失敗都源自於自始至終都搞不清楚要做的是什麼東西。』
漏掉了這些將可補足ㄚ琪對這本書的研讀與瞭解，這一本真是經典。