在精益制造中，对库存的定义非常清晰。它包括额外的原料，生产过程中的原料，以及接下来生产队列中的原料。精益强调减少库存，因为持有库存就意味着产生费用。在软件开发中，需求经常被视为库存，那么，代码呢？　　Michael Feathers建议， 如果你花费大量时间忙于暂时不会实现的功能需求，那么说明你的流程并不顺畅。这显而易见，但除此之外，我们还需要面对一个残酷的现实，一个实实在在需要视为库存的东西：那就是我们的代码。 　　Michael认为，在精益生产中，组件是一个接一个生产出来的。我们通过优化生产流程，从而获得效率。但在软件领域与此有所不同。在这里，团队反复地工作于同一个部件，直到系统被实际应用，该项工作才真正完成。这样，代码也是我们持有的库存，并且需要最小化。 在软件开发过程中，我们实际上经常会持续多年工作于同一个产品。我们使用同样的代码库，我们患难于共。就像在制造业中一样，如果一个由多个零部件组成的模具（在软件领域对应的是代码库）持续用于做同一个产品，它会随着时间的推移而磨损，需要经常打理。所以，对我来说，代码也是库存。它们是闲置的材料，放在那就意味着成本。我们要好好考虑如何让库存最少化。 　　同样，Ori Pekelman也认为代码是债务而不是资产。最开始，团队会编写代码，做出产品，并用它来赚钱，但是，之后团队应该尽可能地寻找减少代码的方法，从而降低成本。Ori认为， 你拥有的代码越多，添加新内容所要付出的成本就越高。更坏的情况是，你所添加的所有内容都会堆在代码的顶端，接下来要添加内容的时候会成本会更高。现在，现存代码的边际负效用（negative marginal utility）并不是固定的：你的代码结构越好，你做了越多的单元测试，你使用的数据库模式越好、越小、耦合越松，那么添加新代码所需要付出的成本就越少。 　　在Boswell和Foucher著的《阅读代码的艺术》一书中，作者强调了轻量级代码库的重要性。他们认为，应付正式系统最好的方式就是要让代码库尽可能小。他们建议采用如下方法： 尽可能创建通用的工具。 删除不用的代码或者特性。 确保项目模块化，并分割成相互没有关联的子项目。 熟悉你经常使用的代码库。 对代码库的规模时刻保持警惕，保持它是小而敏捷的。 　　Kevlin Henney在编写更少代码实践指南中提到，我们有必要删除代码并让代码库的规模更小。 　　这样看来，有足够的理由让我们保持代码库轻而敏捷。就像Michael最后恰如其分地总结： 我认为未来属于知道如何有策略地删除代码的公司。持有代码的成本要比我们想象的大。意识到这一点的公司更具有竞争优势。