or weeks longer to be told that they made an error. These delays made the developers less efficient and lowered the quality of the code they were delivering to be tested. Consider the following conversation I’ve had numerous times with developers.
Me: How many of you would say you spend most of their time fixing bugs?
Developers: (Almost all raise their hands).
Me: Consider what happens if you write a bug and are immediately told there is an error. How long does that take you to fix?
Developer: Not much at all.
Me: Now, consider the same error. But this time, you are not told about it for a week. And imagine nothing else has changed. How long would it take now to fix it?
Developer: Obviously, much more time. And, if something has changed, if someone else has been working on the code, it will take a lot more time! There would be so many changes to have to wade through.
Me: The fix was the same in both cases, but now there is extra work. The delay, from error until detection, caused this extra work. I call this induced work because it was created by the delay.
If you agree with the developers I have talked with, that they spend significant amounts of their time fixing bugs, then surely the amount of induced work we face is significant. That is a lot of dirt!
The common problem: Delay
In software development, there are many different types of induced work; however, they all have a common element: delay. The most common delays are the time between when information is needed and when it is used and between when an error is made and when it is discovered. And they are made worse by delays in getting information needed to act.
The primary cause of delay is doing more than one thing at a time. The math is simple. Doing two things at once doesn’t take twice as much long; it takes twice as much time plus the time to do the newly created (induced) work. Accounting for waiting, detecting, remembering, stopping and starting, the resulting time can be significantly longer.
But, you say, “We need all of this work done. We can’t afford to do them one at a time!”
I have heard this justification time and again. All of the work items are critical. The development teams need to work on all of them. But what we need and what is reality are often different. Imagine being a pilot of a two-engine airplane. The co-pilot says, “Captain, number 1 and number 2 engines are out.” You respond, “That can’t be! I need those engines on!” What you need and what reality is are two different things. The same thing is true with our work; what we need done and what is possible are two different things. To create the greatest chance of getting what we need done, it is critical to avoid creating new work that does not add value.
Focusing on productivity actually works against us
Can we just make developers more productive? If they just worked smarter not harder, wouldn’t they be able to get it all done? We have all tried this. It does not work. On the contrary, going for increased productivity directly usually results in decreased productivity. Why? Because keeping people productive means keeping them busy, even if that means starting new tasks before completing old ones. This creates multiple things being working on simultaneously and that means induced work (think back to Figure 1).
Let’s see how this happens. Imagine a development