In lean manufacturing, the definition of inventory is pretty clear. It is the extra material, work in progress material and material queued up for the next bit of work. Lean emphasizes on reducing the inventory because there is always an inventory handling costs. In software development, often requirements are seen as inventory, what about the code?
If you spend a lot of time elaborating requirements for features you are not going to work on for a while your process isn't streamlined enough. That's fair, but I think that the brutal reality is that we have something much more tangible that we can see as inventory: our code.
According to Michael, in Lean manufacturing, components are made one by one. Real efficiencies can be gained by streamlining how the pieces go through the process. Things are different in software. Here teams are working on the same piece again and again. It is not quite done till the system is being used. Hence, code is a live inventory that we carry through and it needs to be minimized.
In software development, we are essentially working on the same car or widget continuously, often for years. We are in the same soup, the same codebase. We can't expect a model based on independence of pieces in manufacturing to be accurate when we are working continuously on a single thing (a codebase) that shows wear over time and needs constant attention. No, to me, code is inventory. It is stuff lying around and it has substantial cost of ownership. It might do us good to consider what we can do to minimize it.
Likewise, Ori Pekelman suggested that code is a liability than an asset. Initially teams would have to write code to make the product which would fetch money, however later, teams should find ways to reduce the code as much as possible to keep the costs low. According to Ori,
The more code you have, the costlier it will be to add anything new. And the real bad news is that everything you add will just pile up on top of the "code that is" making every subsequent addition even costlier. Now the negative marginal utility of the existing code is not a fixed quantity : the better structured you code is, the more unit tests you have, the more cool schema-less or loose schema databases you use, the less new code is costly.
In the book, The Art of Readable Code by Boswell and Foucher, the authors stressed on the importance of lightweight code bases. According to them, the best way to cope up with a production system is to keep the codebase as light as possible. Some of the ways suggested were,
- Create as much generic utilities as possible.
- Remove unused code or unused features.
- Keep project modularized into disconnected sub projects.
- Be familiar with the libraries around you.
- Always be conscious of the weight of the codebase, keep it light and nimble.
Kevlin Henney mentioned a strong need to remove code and make it lightweight as a possible in his practical guide to writing less code.
Thus, there are strong reasons to keep the codebase light and nimble. As Michael aptly summed it up,
I think that the future belongs to organizations that learn how to strategically delete code. Carrying costs are larger than we think. There's competitive advantage for companies that recognize this.
