What I Wish I'd Said for the Lightning Talk: 100% Utilization

I did decide to talk about how we got started on 100% utilization and what to do about it. I didn’t say everything I wanted to say, so here is what I wish I’d said: How 100% Utilization Got Started Back in the early days of computing, machines were orders of magnitude more expensive than programmers. In the ’70s, when I started, companies could pay highly experienced programmers about $50,000 per year. You could pay those of us just out of school less than $15,000 per year, and we thought we were making huge sums of money. (We were.) In contrast, companies either rented machines for many multiples of tens of thousands of dollars per year or bought them for millions. You can see that the scales of salaries to machine cost are not even close to equivalent. When computers were that expensive, we utilized every second of machine time. We signed up for computer time. We desk-checked our work. We held design reviews and code reviews. We received minutes—yes, our jobs were often restricted to a minute of CPU time—of computer time. If you wanted more time, you signed up for after-hours time, such as 2am-4am. Realize that computer time was not the only expensive part of computing. Memory was expensive. Back in these old days, we has 256 bytes of memory and programmed in assembly language code. We had one page of code. If you had a routine that was longer than one page, you branched at the end of a page to another page that had room that you had to swap in. (Yes, often by...

Costs of Multitasking

  I’m trying to describe the costs of multitasking. Here’s what I’ve got so far: There are three parts to multitasking: Stopping the work you’re doing. The stopping cost is the time it takes to mark your place, save your work, etc. You haven’t stopped thinking about what you’re doing, but when you stop to take a phone call or answer a question, there’s a stopping cost. If you’re in flow, this is surprisingly high. Swapping out what you’re working on. The swapping out is the act of clearing your mind of the work you’d been doing so you have room to swap in the new work. If you were in flow or concentrating deeply, this can take anywhere from 5 minutes to 30 minutes. Sometimes, it takes me even longer. Swapping in the new task. The swapping in depends on the complexity of the work and how long it’s been since you last touched the task. The more complex and the longer the time since you last touched the task, and the more people you have to talk to, the longer it takes. I don’t know how to give ballparks for each of these. Certainly, for some tasks, it’s fairly trivial. If I’m organizing a normal weekday dinner, my swapping in/out is very fast, because there’s little knowledge associated with each task. But now when I write chapters of a book (or back when I was writing code,) the costs can be very high, because the knowledge in my head is not yet written down. For me, the stopping the work is defect-inducing. Unplanned interruptions help me make...

Convincing Management That Context Switching Is a Bad Idea

A few weeks ago, I republished an article originally published in Better Software: Convincing Management That Context Switching Is a Bad Idea on the AYE site. I’d received no feedback about the article when it was published, so I wanted to generate some discussion about my ideas. I did generate a little discussion. Don Gray first said “Context switching is fun!“. Later on, he said the differences were: ¬†One switches between similar tasks, the other doesn’t. I’m not under deadline pressure. (Should anyone be?) I get to choose when to switch contexts. George Dinwiddie discusses the issues of flow in his Context Switching post and the consequences of being interrupted. Don Gray in Context Switching -Congruent Action¬†discusses why managers feel it’s ok to ask people to do multiple things. I still think managers assign people to context switch for these reasons: The manager can’t decide what’s most important. The manager doesn’t understand/remember that technical work is different from management work, and that the more things a technical person works on, the less that person will get done and the worse the work is. The manager can’t remember all the work required and doesn’t realize he or she is asking one person to work on more than one thing. The manager still believes that people who multi-task are more efficient or get more work done than people who don’t. Do you have better arguments than mine? What do you...

Managing Multi-Tasking in a Small Group

A reader sent me email with this question: “We have a group of four people (3 developers and a tester). We work on 4 products, releasing one about once a month (each product is released once a quarter). The developers are devoted to one product when they’re developing, but have to fix problems immediately if someone finds a problem and reports it. How do I manage the multi-tasking?” I’ve asked the reader a few questions. I still don’t know everything about the environment, but here’s what I suspect is happening, based on my questions: Each product has technical debt, from insufficient testing (all the way through development) from previous releases. There are a ton of ways to deal with insufficient testing. I would first start with peer review of fixes. If someone is interrupted from new development to deal with an already-existing, but newly discovered problem, have the developer ask a peer to review the fix. Part of the peer review would be to create automated tests for this fix. (Yes, I realize this now interrupts two people. I find that if there’s a Big Problem in one product, there are frequently other related Big Problems in the related products.) After peer review and automated tests, I would (gently) ask the tester how the tester missed this problem. This is for root cause analysis, not to assign blame. The tester doesn’t read or write code, so the tester can only perform black box testing. Black box testing, by its very nature, is unlikely to find most of the gotcha’s in a product. After a short root cause analysis, I...

Making the Problems of Multitasking Real

  Clarke Ching’s Multitasking MAKES YOU STUPID is another great article. But when I teach PMs or coach managers, they say, “I need to multitask to get things done.” Or, they say, “I’m ok with multitasking.” Even smart people think they can do a couple of things at one time. Maybe they can. But the more things you try to focus on, the less overall you do. Think about that word focus for a few seconds. When you focus on something, you concentrate. If you’re attempting to think or work on several different things, you’re not focusing on anything. I once worked for a company who decided its mission was to “focus on five.” Even then, I knew five was too big a number. But when I suggested we focus on two, my suggestion was dismissed. Company no longer exists. Deciding what to do –and what not to do — is not simple. I just created a simulation (Esther reviewed it for me) to hammer home the point that we all have a limited attention span, and when we pay the necessary attention to one thing, we’re not paying attention to something else. In the simulation, people have to make choices about what to do and what not to do. I’m using the simulation for the first time next week. We’ll see how it goes. Maybe I’ll be able to report back. If you’re faced with multitasking demands, stop for a few seconds. What’s the most strategically important work? Do that first. If you have three or seventeen things you think are all at the same importance and you...