苦：人們通常希望項目快結束的時候收斂的快一點，但結果是越到最後，收斂越慢。
第二章 人月神話（人月：一個人幹一個月，三個人幹四個月就是12個人月）
人月是一個危險的帶有欺騙性的神話，人員和時間的關係不一定是人越短，項目完成時間越少。除非是完全可分解任務，人與人之間不用溝通。有時候盲目增加人員只會適得其反。
進度安排中，系統測試階段往往容易安排錯誤，不確定性太大。編碼階段最容易估算時間
軟件進度安排經驗：1/3 計劃，1/6編碼，1/4構件測試和早期系統測試，1/4系統測試。測試佔一半時間，這是實際中經常做不到的。
Brooks法則：向進度落後的項目中增加人手，只會讓項目更落後。 應該及時修改進度安排和減少項目任務
大型隊伍時，要有系統架構師，要能清晰的劃分體系結構設計和實現之間的界限，並專注於體系結構
貴族專制好，由智力精英完成創造性工作，其他人做齒輪（齒輪的描述其實不對，程序的實現也是創造性工作），這樣有助於概念完整性。但上面的人不用要求下面的人如何做
在體系結構隊伍設計時，實現人員幹什麼？如果讓實現人員參與計劃設計階段，並不會加快速度，並且質量更加低劣。所以大型項目可以分階段，在說明編寫好之後再調入實現人員
功能和理解上的複雜程度的比值纔是系統設計的最終標準，而不是豐富的功能。
儘早交流和持續溝通能使結構師有較好的成本意識，以及使開發人員獲得對設計的信心，並且不會混淆各自的責任分工。
結構師如何成功地影響實現： 牢記是開發人員承擔創造性和發明性的實現責任，所以結構師只能建議，而不能支配
時刻準備着爲所指定的說明建議一種實現的方法，同樣準備接受其他任何能達到目標的方法
規格說明作者應該追求的精確程度：在仔細定義規定什麼的同時，定義未規定什麼。
項目經理最好的朋友就是他每天要面對的對手——獨立的產品測試機構/小組
僅僅通過對編碼部分的估計，然後應用任務其他部分的相應係數，是無法得到對整個任務的估計的。
工作量是規模的冪函數（不是成正比，規模越大，需要的工作量呈冪函數增加）
對常用的編程語句而言，生產率似乎是固定的。這個固定的生產率包括了編程中需要的註釋，並可能存在錯誤的情況。
培養開發人員從系統整體出發、面向用戶的態度是軟件編程管理人員最重要的職能。
對於計算機硬件開發項目，關鍵文檔是：目標、手冊、進度、預算、價格
對於軟件項目：目標、用戶手冊、內部文檔、進度、預算、組織機構圖、工作空間分配
在軟件開發的過程中，往往第一個系統存在的問題挺多，它可能太慢、太大，而且難以使用，或者三者兼而有之。要將誒絕所有的問題，除了重新開始以外，沒有其他的辦法。系統的丟棄和重新設計可以一步完成，也可以一塊塊地實現。這是所有大型系統開發必須完成的步驟。
用戶的實際需要和用戶感覺會隨着程序的構建、測試和使用而變化。
軟件產品易於掌握的特性和不可見性，導致它的構建人員面臨永恆的需求變更。
拋棄原型概念本身就是對事實的接受——隨着學習的過程更改設計。
對於一個廣泛使用的程序，其維護總成本通常是開發成本的40%或更多。
程序維護中的一個基本問題是——缺陷修復總會以固定（20%~50%）的機率引入新的bug。整個過程是前進兩步，後退一步。
系統軟件開發是減少混亂度（減少熵）的過程，所以他本身是處於亞穩態的。
軟件維護是提高混亂度（增加熵）的過程，即使是最熟練的軟件維護工作們也只是放緩了系統退化到非穩態的進程。
調試是系統編程中很慢和較困難的部分，而漫長的調試周轉時間是調試的禍根。
重大災害是比較容易處理的，它往往和重大的壓力、徹底的重組、新技術的出現有關，整個項目組通常可以應付自如。 但是一天一天的進度落後是難以識別、不容易防範和難以彌補的。
進度表上的每一件事被稱爲“里程碑”，它們都有一個一個日期。里程碑的選擇只有一個原則，那就是里程碑必須是具體的、特定的、可度量的事件，能夠進行清晰定義。
自文檔化的程序：將文檔整合到源程序，這對正確維護是直接有力的推動，保證編程用戶能方便、及時地得到文檔資料。
第一是藉助那些出於語言的要求而必須存在的語句，來附加儘可能多的“文檔”信息。