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.
About the author
Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:
- Manage Your Job Search
- Hiring Geeks That Fit
- Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
- The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
- Behind Closed Doors: Secrets of Great Management
- Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People
Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.
User Comments
I remember when I was in university we used learned Assembly language and we had to develop projects using Assembly.
The only thing I remember about Assembly code (other than MOV and INT) is that its code was the absolute definition of spaghetti code.
I remember that the final project was to create a traffic light (red, green, orange) that will work the same way a traffic light does.
Thank you Dennis Ritchie for creating C (and ridding us all of Assembly).
Just wondering which rock the "manager" had been hiding under for the last 20 years. The myth of 100% utilisation was debunked a couple of decades ago during industrial disputes which led to things like mandatory breaks, changes to work design approaches and - with the advent of the PC - legal requirements around hourly breaks for computer users.
Even without Agile a half decent Project Manager will not plan to that level of workload. In call centre environments I worked in full utilisation was not even considered as viable.
Agile and lean don't make this myth transparent - solid management does.
Just wondering which rock the "manager" had been hiding under for the last 20 years. The myth of 100% utilisation was debunked a couple of decades ago during industrial disputes which led to things like mandatory breaks, changes to work design approaches and - with the advent of the PC - legal requirements around hourly breaks for computer users.
Even without Agile a half decent Project Manager will not plan to that level of workload. In call centre environments I worked in full utilisation was not even considered as viable.
Agile and lean don't make this myth transparent - solid management does.
Just wondering which rock the "manager" had been hiding under for the last 20 years. The myth of 100% utilisation was debunked a couple of decades ago during industrial disputes which led to things like mandatory breaks, changes to work design approaches and - with the advent of the PC - legal requirements around hourly breaks for computer users.
Even without Agile a half decent Project Manager will not plan to that level of workload. In call centre environments I worked in full utilisation was not even considered as viable.
Agile and lean don't make this myth transparent - solid management does.
Just wondering which rock the "manager" had been hiding under for the last 20 years. The myth of 100% utilisation was debunked a couple of decades ago during industrial disputes which led to things like mandatory breaks, changes to work design approaches and - with the advent of the PC - legal requirements around hourly breaks for computer users.
Even without Agile a half decent Project Manager will not plan to that level of workload. In call centre environments I worked in full utilisation was not even considered as viable.
Agile and lean don't make this myth transparent - solid management does.
Ross, the rocks still exist everywhere. I wish they didn't, but they do. Otherwise very sharp managers still think that people must be fully loaded.
it's a mystery to me.
Ross, the rocks still exist everywhere. I wish they didn't, but they do. Otherwise very sharp managers still think that people must be fully loaded.
it's a mystery to me.
Ross, the rocks still exist everywhere. I wish they didn't, but they do. Otherwise very sharp managers still think that people must be fully loaded.
it's a mystery to me.
Ross, the rocks still exist everywhere. I wish they didn't, but they do. Otherwise very sharp managers still think that people must be fully loaded.
it's a mystery to me.
Nice Johanna! I like the analogy with multi-process CPU utilization, which hadn't occurred to me before.
I'd like to remind everyone about Tom DeMarco's good book on this very subject (published in 2001):
Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency
http://amzn.to/yrESAv
Pages