在精益製造中，對庫存的定義非常清晰。它包括額外的原料，生產過程中的原料，以及接下來生產佇列中的原料。精益強調減少庫存，因為持有庫存就意味著產生費用。在軟體開發中，需求經常被視為庫存，那麼，程式碼呢？
Michael Feathers建議，如果你花費大量時間說明暫時不會實現的特性需求，那麼就說明你的流程並不順暢。那很清楚，但是我認為，我們需要面對殘酷的現實，應該把更多實際的東西視為庫存：那就是我們的程式碼。
Michael認為，在精益生產中，元件是一個接一個生產出來的。我們應該儘量讓各個部件順暢地經過流程，從而獲得效率。但在軟體領域與此有所不同。在這裡，團隊會一次又一次地針對同一個部件工作。直到系統被實際應用，該項工作才真正完成。這樣，程式碼也是我們持有的庫存，並且需要最小化。
在軟體開發過程中，我們實際上經常會持續多年處理同一部件。我們在相同的基礎程式碼中舉步維艱。當我們持續處理單獨的事物（程式碼庫）時，它會隨著時間的改變而變的越來越陳舊，並需要經常的關注，我們無法期望它和生產業的零件一樣具有獨立性。所以，對我來說，程式碼也是庫存。它們到處散落，儲存這些程式碼需要付出實際的成本。考慮一下我們怎麼做才能讓它最小化，這是很有好處的。
同樣，Ori Pekelman也認為程式碼是債務而不是資產。最開始，團隊會編寫程式碼，做出產品，並用它來賺錢，但是，之後團隊應該儘可能地尋找減少程式碼的方法，從而降低成本。Ori認為，[INDENT]你擁有的程式碼越多，新增新內容所要付出的成本就越高。更壞的情況是，你所新增的所有內容都會堆在程式碼的頂端，接下來要新增內容的 時候會成本會更高。現在，對現存程式碼的負面邊緣應用量（negative marginal utility）並不是固定的：你的程式碼結構越好，你做了越多的單元測試，你使用的資料庫模式越好、越小、耦合越鬆，那麼新增新程式碼所需要付出的成本就越 少。
在Boswell和Foucher著的《閱讀程式碼的藝術》一書中，作者強調了輕量級程式碼庫的重要性。他們認為，應付正式系統最好的方式就是要讓程式碼庫儘可能小。他們建議採用如下方法：
- 儘可能建立通用的工具。
- 刪除不用的程式碼或者特性。
- 確保專案模組化，並分割成相互沒有關聯的子專案。
- 熟悉你經常使用的程式碼庫。
- 對程式碼庫的規模時刻保持警惕，保持它是小而敏捷的。
Kevlin Henney在編寫更少程式碼實踐指南中提到，我們有必要刪除程式碼並讓程式碼庫的規模更小。
這樣看來，有足夠的理由讓我們保持程式碼庫輕而敏捷。就像Michael最後恰如其分地總結：
我認為未來屬於知道如何有策略地刪除程式碼的公司。持有程式碼的成本要比我們想象的大。意識到這一點的公司更具有競爭優勢。
原文：Code is Liability， the Less the Better
譯文：infoQ中文