The Carrying-Cost of Code: Taking Lean Seriously

[From the Archive: Originally posted at Amplify.com Jun 5, 2011]

A somewhat tardy response to a recent blog post by @mfeathers. http://goo.gl/9KUGq

Amplify ’d from www.twitlonger.com

@mfeathers /cc @markdalgarno

Re: The Carrying-Cost of Code: Taking Lean Seriously http://goo.gl/9KUGq

I was with you all the way until your assertion that “code is inventory”. (And only dysfunctional Lean Software Development groups have “chosen to see tasks as pieces”).

In software development we are not “essentially working on the same car or widget continuously, often for years”. We are working on the *designs* for the same make or model of car, continuously, often for years. Regularly (as regularly as every couple of weeks, or even every couple of hours, for some web companies) we pass the latest design to the “factory” and another car instance pops out and passes into service.

To me, requirements (user stories in the product backlog) and everything downstream from there (including code, and even testing effort) is inventory. In fact, borrowing from Theory of Constraints’ definition of the term, I hold that inventory is “everything that a business spends money on (e.g. buying or building), that it might expect to sell again some time later”.

And inventory itself is not necessarily a bad thing. It’s the *carrying costs* of inventory that suggest we might do well to minimise it. Yes, code certainly has carrying costs. But so do many of the other assets/artefacts that arise during the process of software development.

-Bob

P.S. Thanks for your patience. And I’ve posted here as your blog post seems to not want to accepts comments any more.

Read more at www.twitlonger.com