In the '90s, even as the prices of computers, disks, and memory fell, and as programmers and testers became more expensive, it was clear to some of us that software development was more collaborative than just a developer one on one with his computer. That's why Watts Humphrey and the Software Engineering Institute gained such traction during the '90s. Not because people liked heavyweight processes, but because, especially with a serial lifecycle, you had to do something to make system development more successful. And, many managers were stuck in 100 percent utilization thinking. Remember, it hadn't been that long since 100 percent utilization meant something significant.
Now, remember what it means when a computer is fully utilized and it’s a single-process machine: It can do only one thing at a time. It can’t service any interrupts. It can’t respond to any keystrokes. It can’t update its status. It can only keep processing until it’s done.
Now, if the program is well behaved, and is not I/O bound, or memory bound, or CPU bound, and is a single-user, single-process machine, such as a personal calculator that only adds, subtracts, multiplies, and divides, that’s probably fine. But as soon as you add another user to the mix, or another process, you are in trouble. (Or, if the program is not well behaved and does not finish properly, you are in trouble.)
And that’s what we have with modern computers. Modern computers are multi-process machines.
With multi-process machines, if a computer is fully utilized, you have thrashing, and potential gridlock. Think of a highway at rush hour with no one moving; that's a highway at 100 percent utilization. We don't want highways at 100 percent utilization. We don't want current computers at 100 percent utilization either. If your computer gets to about 50 to 75 percent utilization, it feels slow. And, computers utilized at higher than 85 percent have unpredictable performance. Their throughput is unpredictable, and you can’t tell what’s going to happen.
Unfortunately, that’s precisely the same problem for people.
Why 100% Utilization Doesn't Work for People
Now, think of a human being. When we are at 100 percent utilization, we have no slack time at all. We run from one task or interrupt to another, not thinking. There are at least two things wrong with this picture: the inevitable multitasking and the not thinking.
We don't actually multitask at all; we fast-switch. And we are not like computers that, when they switch, write a perfect copy of what's in memory to disk and are able to read that back in again when it's time to swap that back in. Because we are human, we are unable to perfectly write out what's in our memory, and we imperfectly swap back in. So, there is a context switch cost in the swapping, because we have to remember what we were thinking of when we swapped out. And that takes time.
So, there is a context switch in the time it takes us to swap out and swap back in. All of that time and imperfection adds up. And, because we are human, we do not perfectly allocate our time first to one task and then to another. If we have three tasks, we don’t allocate 33 percent to each; we spend as much time as we please on each—assuming we are spending 33 percent on each.
Now, let me address the not-thinking part of 100 percent utilization. What if you want people to consider working in a new way? If you have them working at 100 percent utilization, will they? Not a chance. They can't consider it; they have no time.