繼續延續之前的 Part 2，這篇就由書中的第九章開始了。
第九章 地盡其利，物盡其用
這一章，主要是在討論該如何去節省程式所需要的記憶體空間。作者花了不少篇幅在講節省記憶體的重要性，但是在 Heresy 來看，其實現在一般桌上型的程式開發，其實記憶體使用量這個問題已經沒有這麼大了！當然，並非現在的程式就不用去考慮記憶體的使用，但是相對的，現在的電腦可用的資源變多，所以其實在 Heresy 來看，並沒有必要像以前一樣為了一點點的記憶體使用而斤斤計較，與其想辦法去省 1k、1m 的記憶體，倒不如把精力放在想辦法讓程式跑更快上面（不過這也取決於開發的環境、以及要開發的程式種類）。
這樣講並不是說這章講的東西都沒用了，只是 Heresy 個人會覺得，對於一般性的程式開發來說，這邊的內容有不少部分或許算是有點過時了。而 Heresy 在這邊，則是選一些 Heresy 自己覺得在現況比較有用的建議：
- 鼓吹系統的整體觀和使用者導向的態度，也許是軟體管理者最重要的職責。
- 在大型專案中，每個小組傾向於為了自己的目標，只求局部上的最佳化，而不會思考呈現給客戶的整體效果，這種惡質文化是大型計劃裡的主要風險。
- 要在空間和時間的取捨上做出良好的決定，開發團隊就必須在程式設計的技術上受過訓練，求其在面對一個新語言或新型機器的時候。
- 又小、又快、又好的程式，幾乎源自於策略上的突破，而非技術上的取巧。
- 更常發生策略突破是來自於重新思考資料結構，資料的呈現方式是程式設計的本質。
第十章 文件假說
所謂的文件假說，就是：「在成堆的書面資料中，有一小部分關鍵性文件記錄著專案管理的核心工作，而這些文件就是身為管理者最重要的工具」。而在維護這些文件的同時，就是在執行監督和預警機制的工作，也可以直接拿來當作檢查列表、狀態監控之用。
不管多小的專案，都應該要有這樣的正式管理文件，其原因為：
- 只有真正寫下來，遺漏和矛盾之處才會顯露出來；也只有寫出來，才能導引出更多的細節決定。
- 專案管理者的工作主要是溝通，而非做決策；文件有助於將規劃與決策的結果傳達給整個團隊，更容易讓組織內的所有人朝同一個方向前進。
- 文件提供管理者一個資料庫和檢查列表，可用來檢查目前的位置、看看是哪裡走偏了。
而作者也舉了三種文件的需求來當作例子：
- 規劃電腦產品的文件
- 目標、規格、時程、預算、組織編制圖、場地配置
- 預估、預測、定價，這三者會循環影響，也決定了專案的成敗
- 規劃大學系所的文件
- 目標、課程說明、學位要求、研究提案、課程與教學計畫、預算、場地配置、師資與研究生配置
- 規劃軟體開發專案的文件
- 目標、規格、時程、預算、場地配置、組織配置圖
第十一章 失敗為成功之母
本章的一個重點，是「把必然的第一次失敗納入正式計畫之中」；也就是，不用去擔心是否要做一個試探性的系統，然後將之丟棄，因為到時候你勢必會這麼做。
不過實際上，作者在本書的第十九章，則是又提出了他認為這樣是錯的，因為這個說法過度地簡化了問題；因為這個說法隱含了一個前提，那就是軟體的創作是採用傳統的循序式、或「瀑布模型」的方式（如右圖）。
瀑布模型的謬誤，一個是假設錯誤全部發生在實現階段，所以，這些錯誤的修正工作都可以很順利地在模組測試和系統測試的階段中進行安排；另一個則是假設可以一次建構出整個系統，能在所有實作設計、大部分的程式編寫、許多的模組測試都完成之後，結合所有的程式片段來進行整合的系統測試。
這樣產生的問題點就在於：瀑布模型是把系統測試放在開發程序的最後投，這意味著使用者測試是最後才做的，於是當發現最後的成品糟糕到使用者無法接受時，一切已經太晚了。
而比較好的解法，則是改採用「漸進式的開發模型」。Harlan Mills 建議，先建立一個當作主要迴圈的「polling loop」，必為所有功能（模組）準備副程式來由主要迴圈呼叫，然後對他進行編譯、測試。
而在初期這些模組都可以是空的、什麼都不做，之後再慢慢地把模組一個一個地補上、增加；如此一來，不管在任何階段，隨時都保有一個可以運作的系統！之後，就可以再來針對所有的模組、包括主要迴圈來做調整、修改，以完成需求。
這樣的好處呢，就是由於系統隨時都可以運作，所以可以很早就開始進行使用者測試，同時也可以採取有多少錢就做多少事的策略。
上面都是二十周年紀念版裡第十九章的內容，主要是針對這一章的概念作一些修正；而雖然作者已經修正了「建構一個必然會失敗的系統」的想法，不過在這章內，還是有不少想法是值得參考的。
其中一個很重要的想法，就是在把真正的產品交付出去前，先試做一個系統，也就是所謂的 Beta 版、甚至是有限功能的原型 Alpha 版。此外，軟體開發也常常會面臨客戶在目標和需求上的改變，要接受多少變化是很難決定的，但是定義出一個底線是必須的，而且隨著專案的進行，這項限制應該要越來越嚴格，否則沒有任何一項產品會完成。
其他還包括了：
- 使系統例於改變
- 例如採用結構化程式設計、加上模組的詳細說明、使用 table-driven 的技術（將參數存在表格裡，而不寫死在程式中）。
- 把改變量化，使產品具有明確的版本編號、凍結日期。
- 使組織利於改變
- 當今軟體團隊失敗的共通原因不是因為太多管理，而是缺乏管理。
- 在大型專案中，通常要保留兩到三位頂尖的程式設計師來當機動部隊。
- 管理和技術人員能力許可的話，就應該保持這兩種不同的腳色的職位互換。
- IBM 建立的雙梯式（dual ladder）的晉升架構，讓管理和技術兩種對應的職位在制度上位階是平等的。
- 採用第三章所提的「外科手術團隊」的概念。
而在軟體後續的維護上，作者也有做出一些討論：
- 軟體維護的主要目的是修正錯誤、增加新功能、因應環境和組態的變化而調整。
- 要維護一個廣為使用的軟體，起碼要付出開發成本 40% 的代價；使用者越多，維護成本就越高。
- 維護軟體最大的問題，就是因為修正錯誤而導致其他錯誤的可能性相當高（30% – 50%）。因此，每修正一個錯誤後，都應該要把之前的測試案例（test case）都拿來測一次，進行迴歸測試（regression test）。
- 實作時，用較少的人、較少的介面，錯誤也會比較少。
在軟體改版的部分：
- 模組的數量會隨著版本編號呈線性遞增，但是模組間的牽連程度卻是成指數遞增。
- 任何動作都有破壞原有軟體結構的傾向，並且會增加系統的混亂程度；到最後會變成無法再進行修改，只能重新設計。
第十二章 神兵利器
這章主要是在討論工具的重要性。作者認為，專案經理必須要建立一套運作哲學，不但要配置資源已建立共用工具，也要認知到特殊化工具的需要，不吝於他的團隊建立屬於自己的工具。
在機器設備的部分，應該要分為「目標機器」（target machine）和「工具機器」（vehicle machine）；前者就是要執行最後結果的機器、而後者則是在開發階段要用的機器。不過以目前一般的軟體開發來說，目標機器和工具機器在很多狀況下，應該是同一台。但是如果目標機器比較特別，有數量限制、而又有許多團隊要使用的話，就需要想辦法共用了。而在這種情況下，比較好的分配辦法，應該是切割較長的使用時間，給每個團隊各自的使用權限，這樣會是比較有效率的方法。
而如果是新機種的話，最好還能有他的邏輯模擬器（logical simulator），在真正的機器但生前，當作除錯用的工具。即使在新的機器已經準備好的情況下，邏輯模擬器應該也會是個相對可靠的除錯工具。
在程式庫的部分，應該要分為三個區塊：
- 局部自由區塊（playpen）：個人任意使用
- 系統整合子程式庫（system integration sublibrary）：需要整合管理員同意方可變動，做為系統測試之用
- 現行版本子程式庫（current version sublibrary）：除非有重大錯誤，不然不輕易修改。
這裡的概念，主要是「控制」（由管理者來控制異動）和「區隔」（將正式、整合、局部自由區塊三者做區隔）。
除了這些以外，作者也有強調高階程式語言（high-level language）和交談式程式編寫（interactive programming）的重要，這兩者都可以有效地提高生產力。而實際上，在現在的環境裡，這兩種東西也都已經算是廣被接受了。
Heresy's Space 