这是人月神话：软体专案管理之道（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)，将是这篇的结论，有时我们都会钻牛角尖在一个地方上，我习惯称之为局部最佳化的瓶颈，但是如果有办法跳出这个局部的话，你可能可以看到全部最佳话的可能性，有时我们称不能，在神永远都能，试着用你的灵感想想，会让我们收获很多！