1、對於大多數項目，第一個開發的系統並不合用。可能太慢、太大，而且難以使用，或者三者兼而有之。要解決所有的問題，除了重新開始以外，沒有其他的辦法，即開發一個更靈巧或者更好的系統。系統的丟棄和重新設計可以一步完成，也可以一塊塊地實現。所有大型系統的經驗都顯示，這是必須完成的步驟；
2、一旦認識到實驗性的系統必須被構建和丟棄，具有變更思想的重新設計不可避免；
3、用戶的實際需要和用戶感覺，會隨着程序的構建，測試和使用而變化；
4、開發人員交付的是用戶滿意度，而不僅僅是實際的產品。一次一個有有經驗的同事這麼和我說，我深受啓發，的確是這樣，既然交付的主要是滿意度，那麼怎麼樣提高用戶的滿意度呢？要麼提高您產品的質量來獲取高的用戶滿意度，要麼降低用戶的期望！vista不好嗎？市場反應不怎麼樣呢？主要原因就是大力的前期宣傳，使用戶的期望值太高了！
5、 爲變化設計系統，包括細緻的模塊化、可擴展的函數、精確完整的模塊間接口設計、完備的文檔。另外，還可能會採用包括調用隊列和表驅動技術。最重要的措施是使用高級語言和自文檔技術，以減少變更引起的錯誤。採用編譯時的操作來整合標準說明，在很大程度上幫助了變化的調整。
6、變更的階段化是一種必要的技術。每個產品都應該有數字版本號，每個版本都應該有自己的日程表和凍結日期。在此之後的變更屬於下一個版本的範疇。
7、爲變更計劃組織架構和團隊，爲變更組建團隊要比爲變更進行設計更加困難。
8、只要管理人員和技術人員的天賦允許，老闆必須對他們的能力培養，給於充分的關注，使管理人員和技術人員具有互換性。
9、程序設計人員，不願意書寫文檔，不僅僅因爲惰性，更多的是來源於設計的躊躇——要爲自己嘗試性的設計決策作辯解。
10、程序維護中的一個基本問題是 -- 缺陷修復總會以(20%--50%)的機率引入新的bug。整個過程是前進兩步，後退一步。作爲引入新bug的一個後果，程序每條語句的維護需要的系統測試比其他編程要多，成本非常高。缺陷不能被徹底修復的原因：
首先，看上去很輕微的錯誤，似乎僅僅是局部操作上的失敗，實際上卻是系統級別的問題。其次，維護人員通常不是編寫代碼的開發人員。
11、對於一個廣泛使用的產品，其維護成本通常是開發成本的40%或者更多；
12、維護成本與產品的使用人數有很大關係，用戶越多，發現的錯誤也就越多；bug數隨着產品的發佈時間的推移，先是下降，然後是上升的；
13、每次修改一個bug，必須運行以前所有的測試用例，確保不會以更隱蔽的方式引入新的bug，這其實就是迴歸測試；
14、 使用能消除、至少是能指明副作用的程序設計方法，會在維護成本上有很大的回報。設計實現的人員越少、接口越少，產生的錯誤也就越少；
15、維護工作破壞系統的架構，增加了系統的混亂程度。隨着時間的推移，系統變得越來越無序，無法再成爲下一步進展的基礎。這時，系統的重新設計完全是必要的。系統軟件開發是減少混亂度的過程，軟件維護是提高混亂度的過程，即使是最熟練的軟件維護工作，也只是放緩了系統退化的進程。
