Inventory vs. Partially Done Work vs. Unused Code

I like the idea from LSD to eliminate waste in the project. LSD defines waste as anything or process that does not add value to a product. There are seven main wastes defined by lean for manufacturing. LSD tries to map them to its own definition but not all of the mappings are in my opinion right. Here the short summary of wastes based on LSD and my opinion.

The Seven Wastes of Manufacturing	The Seven Wastes of Software Development by LSD	The Seven Wastes of Software Development by Boczek.com
Inventory	Partially Done Work	Unused Code
Extra Processing	Extra Processes	Extra Processes
Overproduction	Extra Features	Overdesign
Transportation	Task Switching	Context Switching
Waiting	Waiting	Poor Synchronization
Motion	Motion	Poor Communication
Defects	Defects	Defects
	Management Activities	Management Activities

So let't talk about first one: partially done work and unused code.

Partially Done Work Waste

LSD defines "partially done work"-waste as a counterpart to the "inventory"-waste in the manufacturing industry. I don't agree with this definition. In an agile project "partially done work" does not exist. Iterations are time-boxed and short enough that you have always a good ability to close or continue tasks without leaving something in an "open" or "partially done" state for eternity. But we have other type of "inventory"-waste, which is much more difficult to localize: "unused code"-waste.

Unused Code Waste

In our project I have decided to use DDD. To support this I have built a very, very light initial framework based on component object model principles that means with a lot of interfaces and base classes. An additional untypical constraint we had, was that we were not allowed to use any O/R mapper, thus the whole infrastructure layer (using DDD terminology) had to be written manually (every SQL statement for CRUDs and so on) from the scratch. With help of an O/R mapper you would get almost all CRUDs out of the box.

I am an architect and I love frameworks. I love these hours deliberating about what would be good to build at the beginning of the project to reuse this in the future, to make the life of a normal developer easier. Yeah... It so simple to forget "You aren't gonna need it" (or YAGNI for short). As you probably know YAGNI is the principle in extreme programming, that programmers should not add functionality until it is necessary.

My decision was pretty hard for the whole team: "We will follow YAGNI as close as possible! We will not produce any "unused code"". It was especially difficult for the developers to accept this, in case of building infrastructure layer. Our interfaces have defined CRUDs for every entity and it was very unusual even for me to provide (depending on the business flow) e.g. only an "U" without implementing other "CRD" (exactly speaking, we do have implemented them but with only one line of code throwing Not-Implemented-Exception). But we have done this consequently in the whole application.

And it was a great decision. As we know, agile supports role-less teams, so if someone got Not-Implemented-Exception it was pretty clear, he had to implement lacking functionality and did it without problems. The only small challenge we had was regarding to unit testing. Developers love to test "U" using at the beginning "C". We have solved it providing specialized set of test data, which is always a better solution (separation of functionality being tested) comparing to usage of CRUDs to provide test data dynamically.

So we haven't produced any unused code in our application. We haven't produced any waste! It rocks, hammer hard.