本章談及「軟體的變更（維護）」。
開始，作者寫道：「對於大多數專案，第乙個開發的系統並不好用。……要解決所有的問題，除了重新開始之外，沒有其他的辦法——即開發乙個更靈巧或者更好的系統。系統的丟棄和重新設計可以一步完成，也可以一塊塊地實現。所有大型系統的經驗都顯示，這是必須完成的步驟。而且，新的系統概念或新技術會不斷出現，所以開發的系統必須被拋棄。但即使是最優秀的專案經歷，也不能無所不知地在最開始解決這些問題。」
「是否預先計畫拋棄原型的開發，或者是否將該原型發布給使用者？」
「唯一不變的就是變化本身」（如今，很多人都非常熟悉這句話了）
一旦認識到實驗性的系統必須被構建和丟棄，具有變更思想的重新設計不可避免，從而直面整個變化現象是非常有用的。第一步是接受這樣的事實：變化是與生俱來的，不是不合時宜和令人生厭的異常情況。
cosgrove很有洞察力地指出，開發人員交付的是使用者滿意程度，而不僅僅是實際的產品。（這句話也非常經典，對於任何產品都是如此吧！）使用者的實際需要和使用者感覺會隨著程式的構建、測試和使用而變化。
◆為變更計畫系統
如何為變化設計系統呢？它們包括細緻的模組化、可擴充套件的函式、精確完整的模組間介面設計、完備的文件。另外，還可能會採用包括呼叫佇列和表驅動的一些技術。
變更的階段化是一種必要的技術。每個產品都應該有數字版本號，每個版本都應該有自己的日程表和凍結日期，在此之後的變更屬於下乙個版本的範疇。
◆為變更計畫組織架構
當系統發生變化時，管理結構也需要進行調整。這意味著，只要管理人員和技術人才的天賦允許，老闆必須對他們的能力培養給予極大的關注，使管理人員和技術人才具有互換性。
管理人員需要參與技術課程，高階技術人才需要進行管理培訓。
專案目標、進展、管理問題必須在高階人員整體中得到共享。
◆程式維護
在程式發布給顧客使用後，也會有變更，這個階段的變更被稱為就「程式維護」。程式維護中的乙個基本問題——缺陷修復總會以20%-50%的機率引入新的bug。
作者回答了乙個問題將「為什麼缺陷不能更徹底地被修復？」
首先，看上去很輕微的錯誤，似乎僅僅是區域性操作上的失敗，實際上卻是系統級別的問題，通常這不是很明顯。修復區域性問題的工作量很清晰，並且往往不大。但是，更大範圍的修復工作常常會被忽視，除非軟體結構很簡單，或者文件書寫得非常詳細（這個貌似非常理想化^_^）。其次，維護人員常常不是編寫**的開發人員，而是一些初級程式設計師或者新手（確實如此！）。
最後，作者以一段意味深長的話結尾：
系統軟體開發是減少混亂度（減少熵）的過程，所以它本身是處於亞穩態的。（大部分時候，）軟體維護是提高混亂度（增加熵）的過程，即使是最熟練的軟體維護人員，也只是放緩了系統退化到非穩態的過程。
人月神話（11）未雨綢繆
思維導圖 試驗性工廠和增大規模 唯一不變的就是變化本身 為變更設計系統 如何設計變更系統 變更的階段化是一種必要的技術，每個產品都是應該有數字版本號，每個版本都應該有自己的日程表和凍結時間，在此以後的變更屬於下乙個版本的範疇 為變更計畫組織架構 設計人員不願意為設計書寫文件化的原因 如何設計變更計畫...
人月神話讀書筆記（11） 未雨綢繆
圖為紐約灣的tacoma橋由於空氣動力學上的錯誤設計而坍塌的新聞 1940年11月7日中午時分，建成僅僅數月的tacoma橋坍塌，這是橋梁工程史上著名的悲劇。在做專案設計和規劃時，一定要考慮到各種不確定的變化因素，靈活適應多變的環境，否則很可能釀成悲劇後果。不變只是願望，變化才是永恆。對於大多數專案...
人月神話筆記 焦油坑 人月神話
程式 程式設計系統 程式設計產品 程式設計系統產品 程式設計產品 程式設計系統 程式設計系統產品 美食的烹調需要時間 片刻等待，更多美味，更多享受。good cooking takes time.if you are made to wait,it is to serve you better,an...