Inventory vs. Partially Done Work vs. Unused Code
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.
Comments
Post a Comment