Comments on: inventory in software development

By: Ashley Frieze

Ashley Frieze — Mon, 08 May 2006 15:13:13 +0000

I consider inventory to be any software that we’ve written but have not yet sold a single copy of. Much like the manufacturing-equivalent, where unsold stock sits in a warehouse, this software has cost us money to make, and has also cost lost-opportunity of the workers who made it, who might have made something else that we sold instantly. Although, unlikely manufacturing, it probably takes the same amount of physical storage space for lots of inventory as it does for none (i.e. about the size of a server rack, compare with differening sized warehouses in the physical world), in my opinion, it is still highly undesirable to let completed code remain unsold and unused. If there’s no way this code can be sold now, then perhaps that’s an indication that something else should have been made first. However, there are some reasons I’ve seen given for why “we cannot sell this yet”.

1. We’re waiting for more features, to make a bigger impact.
2. Selling it in this state will give a false impression of the software.
3. Selling it at this stage will give a negative impression of the company.
4. Deploying a new solution is so much work that we can only do it infrequently.

The first three of these come into the category of “minimum marketable feature set”, something which makes sense, perhaps, in the earliest stages of a product, but which, in a mature offering, could be a falsehood, born out of not understanding the customer, having customers with unrealistic expectations, or to cover up inadequacies in the requirements gathering process. If a single story cannot add some measurable value to the product enough to make it worth buying by a customer who needs that value, then the story may not be worth implementing.

Number 4, however, is a compelling argument. If the process of deploying a new version requires a lot of people, training, communications, supporting materials and so on, then perhaps the deployment shouldn’t be done that often, though internal deployment should continue, to ensure feedback etc.

The big problem with inventory, apart from lost opportunity cost, is that it goes out of date. Technology moves, as does our understandings of user requirements. Something I made last year may no longer cut it as the solution a customer wants to use. So, the sooner the code is out of the door, the better. I reckon it’s best to get in there first with something simple and coherent, than join the party increasingly late with something brilliant, but costly.

By: kevin

kevin — Mon, 08 May 2006 13:29:58 +0000

I like the idea that huge libraries incur carrying cost. (And in general I like anything that bashes STL.) In a sense it violates 5S, which seeks to keep the workplace clean, tidy and efficient by eradicating anything that’s not directly needed. Imagine a Toyota production worker having to rummage through packing crates whenever the next nut or bolt was needed…

By: Hugh Sasse

Hugh Sasse — Mon, 08 May 2006 11:34:43 +0000

The article talks about *excess* inventory, which is only inventory in the limiting case.

Your examples mostly include things that get shipped, or are used to support shipping. Po: excess inventory is all the code that doesn’t get used in production or get shipped.

This would suggest that huge, great libraries that come with the language, but are not used directly are a burden. I found that learning to use the Standard Template Library in C++ always seemed to require learning about another part to understand the part I was studying at the time. This is clearly a cost to the programmer, and his/her productivity.

This leads to the idea that procedures that cannot be automated but must be performed are also “stock” that the programmers (et al) must carry. That ties in to earlier blog entries about “Muda” and waling around.