這是人月神話：軟體專案管理之道（20週年紀念版）的第九章：地盡其利，物盡其用，『Ten Pounds in a Five-Pound Sack』在簡體文版本裡反而被翻作『削足適履』，但是如果你查一下成語辭典，這是比喻勉強遷就，拘泥舊例而不知變通。這可跟地盡其利，物盡其用的感覺差很多了，這一篇有幾個主題，空間就是金錢、程式大小的控制、節省空間的技術、資料的呈現方式是程式設計的本質等主題，端看這些主題，ㄚ琪私以為翻成削足適履並不怎麼恰當，所以還是覺得繁體版的翻譯較佳！
第一個主題，我引用一下最後一段的結論：『由於軟體系統的大小對使用者的成本負擔影響非常大，軟體開發人員必須設定空間大小的目標(size target)，進而控制程式大小、發展節省空間的技術，這跟硬體開發人員設定元件數量的目標、控制元件數量、發展減少元件數量的技術是一樣的道理。就像花錢一樣，程式大小本身並沒有錯，但是不必要的空間浪費就不好了。』這段敘述來自35年前，想當然爾似乎不怎麼有用，因為隨著硬體技術的發展，我們發現很多的軟體專案對於程式大小，似乎已不再那麼地強求，因為開發時間似乎已經比開發的空間還要重要了！有時候我們得想想「以空間換時間」的持久戰策略，還有時間本來就是金錢，時間是錢，空間也是錢，反正都是錢，就看哪個成本較低來排優先順序了，況且要空間就跟技術有關係，如果技術夠的話，我會同意盡量節省空間吧！
在假設我們的技術夠的話，我們還需要一些管理的工作，在程式大小的控制這節，還是以OS/360的經驗教訓來解釋，我不想引用太多的文字，只簡述這裡所得到的3個教訓，一『必須做好整體空間規劃(total size budget)，這不單包括了常駐空間規劃(resident-space budget)，背後跟這些有連帶關係的存取動作也應該一併納入考量』，二『在規定某個模組的大小之前，你得先精確定義出這個模組該做的事』，三『由於我們的專案夠大，在管理溝通方面也夠糟，使得團隊中的許多成員都非常本位地謀取自身的績效，並視彼此為競爭對手，每個人未達自己的目標，只求局部上的最佳化，很少人會停下來思考最終呈現給客戶的整體效果，這種惡質的想法和溝通是大型計畫裡的主要風險。』說到這裡，又是牽扯到溝通的問題，所以溝通的學問真的是很大。溝通表達訓練這種技巧已經可以成為一個課程來討論了！
在節省空間的技術上，ㄚ琪只提兩件管理者要做的事，一『確保大家的本事是真正透過程式設計的技術訓練而來，而不是僅憑個人的天賦或過去的經驗。』，二『認知到寫程式有它專業的技術，組件是要去創造才有的。』看了第一點之後，ㄚ琪會更加地退縮，因為竊以為，看起來這種本事很多還是憑天賦來的，當然過去的經驗也是不可少，就因為這樣，所以才能變為本事，所以對此ㄚ琪有不同的意見。
資料的呈現方式是程式設計的本質(Representation is theessence of programming)，將是這篇的結論，有時我們都會鑽牛角尖在一個地方上，我習慣稱之為局部最佳化的瓶頸，但是如果有辦法跳出這個局部的話，你可能可以看到全部最佳話的可能性，有時我們稱不能，在神永遠都能，試著用你的靈感想想，會讓我們收穫很多！