In manufacturing wastes are well documented and generally understood, however in software development waste is acknowledged but usually misunderstood, especially by Microsoft Project Project Managers.  In many circumstances (especially in waterfall shops) the common root of all software waste is deemed to come from not planning enough, or not documenting enough.  Basically, all this effort is expended up front trying to ensure that the cardinal sin is not committed.  What is this sin?  Throwing code away. 

In reality we want to throw away code, as much code as possible.  I'm not saying we should generate code just to throw it away, but we should always be looking for opportunities to trim back the code base.  Less code is easier to maintain and test. 

Developers often think through tough business problems and technical problems by coding.  Coding is not just a statement of some requirement, coding is a mental exercise performed by programmers to better understand the problem domain.  It’s through coding we arrive at greater understanding and insight.  Coding allows us to make logical connections between entities, rules, and requirements.  During this research phase should the code be thrown away?  Not necessarily, but in all likelihood all this code will be thrown away as understanding of the problem domain changes over time.

If what I say is true, then throwing away code is not a waste, in fact throwing away code is quite productive.  Waste in software development comes from other areas.  Mary and Tom Poppendieck make the case that waste in software comes from the same areas as manufacturing, however with a slightly different software twist: