Mary Poppendieck’s seminal work, Lean Software Development: An Agile Toolkit, lists the 7 wastes of manufacturing and maps them to software development, among other things.  (In a recent webcast, Poppendieck added 3 more wastes to the list, and I’ll write about those in another post.)  Of the original seven wastes, the one that I found most enlightening is that unfinished projects lying about is the equivalent of having excess inventory on hand.

“The level of inventory in your system is the amount of stuff you have under development. The more inventory of unfinished development work you have sitting around, the greater you’re at risk of it becoming obsolete, getting lost and hiding defects. If you capitalized it, you also bear the risk of having to write it off if it doesn’t work.” This is the focal point of her analysis of why Dell succeeded in putting Zeos out of business. Zeos was named as a finalist for the Malcolm Baldridge National Quality Award (which would be the equivalent of a CMM Level 5 certification for us software developers). Yet, all of the so-called quality-producing “capability” enshrined in the Zeos procedure manuals couldn’t hold a candle to Dell’s simple 2-pronged vision of keeping inventory to a minimum and delivering product to the customers as quickly as possible.

Furthermore, this concept pertains not only to whole projects, but also to project offshoots.  Martin Fowler wrote of the dangers of “speculative generality” in his Refactoring book, and the Pragmatic Programmer book referred to YAGNI (“you ain’t gonna need it”).  Those are two more ways of looking at the same issue — that any effort spent writing code that isn’t immediately put into use is a waste.