A lot of managers don’t think twice about every day things that slow down developers…

• Slow or unstable development machines
• Delays from business folks in clarifying requirements
• Little to no feedback on the product until it’s already “done”
• Loss of focus from repeated interruptions

And yet, these same managers will often go out of their way to make sure the developers are busy 100% of the time in the name of “getting things done faster.” It’s a little counterintuitive if you stop and think about it. As any good developer knows, optimizing a part of your system that isn’t the bottleneck doesn’t actually speed anything up. In fact, it can actually do more harm then good as optimized code can be more difficult to understand and to work with.

But, anyway, what are those developers so busy working on if they don’t have the information & feedback they need to build the product correctly? Whenever this happens on my projects, all it does is muddy up the code for the rest of us with unnecessary or incorrect functionality that degrades quality and slows us all down. Sort of like Wally’s anti-work…

In Alan Shalloway’s Lean Online Training, we’re learning about the Myth of Optimization Through Decomposition, which states that trying to go faster by optimizing each individual piece does not speed up the system.

In the physical world of manufacturing, attempting to run every single machine at 100% utilization results in large piles of unfinished product just sitting around waiting to get through the next step of the pipeline or for a buyer. These unfinished products incur significant costs in terms of inventory and storage. And, whenever the product line is changed or stopped, whatever is sitting in that pipeline winds up being thrown away. This is why physical operations do best when they use a Just In Time strategy — creating only what they need and no more. It turns out that operating each machine at 100% utilization is actually a really bad business decision.

In the world of software development, the parallel to running every machine at 100% utilization is making sure every employee is busy 100% of the time. And, just like in the physical world, this results in large amounts of unfinished works in progress that incur significant costs and risks. Knowledge degrades quickly, requirements get out of date, the feedback loop is delayed so we don’t learn what we’re doing wrong. The result is unfinished, untested, misunderstood, and often flat-out unnecessary code bogging down our product, degrading its quality, and, actually slowing us down.

• It’s difficult implementing a feature that was specified so long ago that no one can remember what it’s for.

• It’s hard tracking down an error in code developed so long ago that no one remembers how it was implemented.

• It’s slow adding new features when the software is muddled with unfinished, untested code (that isn’t even needed!).

Thus, Lean teaches us that striving for 100% utilization is not the answer. It doesn’t get the product completed any more quickly, and the only thing it creates is waste.

The only way to go faster is the optimize the whole. In other words, find your bottlenecks — the things that are slowing down the process, incurring delays, and adding waste — and remove those. And when you do, a funny thing happens, it lets your developers work faster! They’re happier, you’re happier, and ultimately the customer is happier.

Jeff Sutherland describes this nicely:

“The task then is to refine the code base to better meet customer need. If that is not clear, the programmers should not write a line of code. Every line of code costs money to write and more money to support.

It is better for the developers to be surfing then writing code that won’t be needed.

If they write code that ultimately is not used, I will be paying for that code for the life of the system… If they went surfing, they would have fun, and I would have a less expensive system and fewer headaches to maintain.”

So let’s take their advice and stop wasting our time trying to speed up the things that are working (e.g., writing code against understood requirements). Let’s, instead, spend our time minimizing or eliminating the things that aren’t working. Our goal should be to spend 100% of our working time on productive & useful things, rather than to spend 100% of our time working in the Wally fashion of equal parts work and anti-work.

—
With thanks to Alan Shalloway & NetObjectives for the fantastic free Lean Online Training they’re providing as well as the most excellent chapters of their upcoming book on Lean that they’ve made available on their web site:

» Lean Software Development: Scaling Agile to the Enterprise (free online!) by Alan Shalloway, Guy Beaver, Jim Trott