Waste #1: Partially Done Work
Join the DZone community and get the full member experience.Join For Free
Welcome to episode two of our series "The Seven Wastes of Software Development." In , we introduced the concept of eliminating waste from our software development efforts. Waste elimination can be traced all the way back to the the mid-1900's, the birth of lean manufacturing, and the Toyota Production System (TPS). This is how Taiichi Ohno, the father of the TPS, described its essence:
All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing the time line by reducing the non-value adding wastes. 
Read the other parts in this series:
As you can see, eliminating waste is primarily about speed. How can we reduce the length of the time line?
Think about all of the things that slow you down when you're implementing a feature. Think about all of the things that you must do (or undo!) just so that you can get your "real work," that work that actually adds value to the customer, done. This is your overhead. Overhead equals waste.
The first source of waste that we're going to focus on is partially done work. What is it about partially done work that slows us down? How does it make our jobs as developers more difficult? After all, isn't everything partially done before it's finished? To understand why partially done work is so wasteful, you have to look back at the manufacturing waste that it's drawn from: inventory. For a word on inventory, let's look back at a segment of my earlier article on Kanban:
Minimization of inventory (or WIP) is a hallmark of lean thinking, as inventory is considered a key "waste" of any process. Managing high amounts of inventory (or WIP) increases costs (i.e. warehousing, tracking, loss of value over time, etc.) and hides inefficiencies in the process. By minimizing inventory, we can decrease costs and call attention to process inefficiencies so that they can be improved.
As you can plainly see, it's the management of HIGH AMOUNTS of inventory that's the problem. Following from that, we can see that it's the management of HIGH AMOUNTS of partially done work that's the problem. So what are some of the problems with partially done work?
- Partially done work often becomes obsolete long before it's ever finished. Until software code is released into production, you have no clue whether or not it solves the business problem at hand. And because business problems are a moving target anyway, it's quite likely that you'll solve yesterday's problem rather than today's problem. Or as a wise man once said, you might reach the top of the ladder only to find its leaning against the wrong wall!
- Partially done work ALWAYS gets in the way of other work. Any work that's not checked-in, integrated, tested, and deployed gets in the way of any other development efforts. How many times has an urgent task arrived at your desk and you had to shelve a bunch of code to get back to a stable state? How many times have you been afraid to check-in your code at the end of the day because you're not confident about what you have on your desktop? How long did you let that go? How much harder did it get to work the longer you waited to integrate? These are the questions that show us just how wasteful partially done work can be.
So what are some of partially done work's manifestations? The Poppendieck's provide us with an excellent list in Implementing Lean Software Development :
- Uncoded Documentation - Requirements/features/stories/etc. that are documented far in advance of coding will quickly become obsolete, forcing this work to be repeated before value can be delivered.
- Unsynchronized Code - Code that sits on a developer's workstation for a long period of time makes integrating that code into the shared repository a more difficult task. The same can be said for multiple source control branches that live for long periods of time before being merged into the main line.
- Untested Code - Code without associated automated tests is a breeding ground for bugs. Without tests, you have no way to prove that your code works immediately and repeatably.
- Undocumented Code - Of course, the ideal is self-documenting code. But if you must have separate documentation artifacts, they must be developed in parallel with the code. Otherwise you're only extending the timeline and increasing the chance for errors.
- Undeployed Code - the longer you hold on to your code, the longer it takes to find out if it solves your users problems and delivers value. Also, the longer you wait to deploy, the greater the inventory of undeployed new features. Deploying in a "big bang" will easily overwhelm your users.
Jack Milunsky mentions an additional manifestation in his article on waste #1: commented out code. How many times have you seen the following:
// Save this in case we need it later /* Foo foo = new Foo("Foo"); ... foo.save(); */
While it is indeed true that you might need this later, it doesn't take much leg work to recover it from your source control system. Commenting out "dead" code for later resuscitation only makes the software less readable and maintainable.
I'd like to point out yet another manifestation: copy and paste "reuse." Lifting code from one class and dropping it verbatim into another class is incredibly bad form. If the original code was buggy, all you've done is clone the bug. Copied and pasted code tends to reproduce much like a virus would. Let's assume the best and say that the code was clean and correct. As soon as the business logic needs to change, you have to remember all of the locations and touch them all. It's exactly like storing up inventory for future processing. Processing that is almost guaranteed to happen.
That's all for this episode of "The Seven Wastes of Software Development." Stay tuned for the next installment: Extra Features.
 Ohno, Taiichi. Toyota Production System: Beyond Large Scale Production. Productivity Press, 1988.
 Poppendieck, Mary and Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2006.
Opinions expressed by DZone contributors are their own.