Inventory in software development

One of the central tenets of lean (and TOC, for that matter) is that inventory is not an asset, but is waste. In particular, carrying inventory incurs storage costs.

American Bulk Warehouse Shopping

David Carlton is reading up on lean manufacturing, particularly in relation to applying its techniques to software development. This week David asks a deceptively simple question about inventory:

“… it’s not clear to me exactly what lesson [the carrying cost of inventory] has for software development”

While neither David nor I would claim that software development is similar to manufacturing, it can be edifying to map the themes, principles and practices of the one onto the other. I think the answer to this particular question lies in looking at the various kinds of inventory we have in software development, and examining the carrying costs of each in turn. Off the top of my head:

Unreachable code:
Still gets built, thus contributing to slower build times, and hence to reduction of flow and feedback during coding. It may also need to be read (or worse – understood) whenever we’re debugging or designing an extension in that area. We have to keep it compiling successfully, which means it could actually prevent design changes and cause inertia. And if it has tests, we have to keep them building successfully and passing – another potential cause of reduced speed, frustration and ultimately design inertia. (All of this because our codebase is part of gemba.)
Unused features:
Same as unreachable code, plus: Features we ship get in the way of our users, which will either confuse them, slow them down, or otherwise generally leave them feeling slightly uneasy about our product. And presumably our testers still have to ensure that the features do work as intended, so there’s extra pointless work to do for each release. And if these features have bugs, we have to carry the support cost when a user stumbles upon one.
Items in the product backlog:
Have to be reviewed whenever stories are prioritised. And if we have too many, they may contribute to a sense that the product is a Death March.
Artefacts that don’t ship:
By which I mean documents, plans and models that must be kept up-to-date as the fuzzy future comes into focus, and as the product evolves. None of these artefacts is directly a part of the product, and yet we spend time and money fiddling with them (while Rome burns).

(And we haven’t even mentioned the time and money invested in creating these things in the first place!)

What other inventory and carrying costs does your project have?

3 thoughts on “Inventory in software development

  1. 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.

  2. 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…

  3. 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.

Leave a Reply to Hugh Sasse Cancel reply


You are commenting using your account. Log Out /  Change )

Google photo


Twitter picture


Facebook photo


Connecting to %s