Multiple Projects
Work in progress and I have an interesting relationship. I understand, both intellectual and viscerally, that regularly working on multiple things at once takes longer than doing the first things first. Motion is not the same as progress, and just because you’re busy doesn’t mean you’re adding value. On the other hand, sometimes there are external events you need to wait for. Doing nothing in those cases doesn’t help anyone. While not all motion is progress, lack of motion is lack of progress. Sometimes it is the right thing to do, but when?
The first thing to think about is to compare the time spent on a project to the time spent switching between projects, the context switch time. If you’re talking about writing a design document in the morning, responding to email right after lunch, and then debugging an outage in the afternoon you may or may not be switching projects. Over the day you’ve done at least 3 things, but you were probably working on the same overall project. On the other hand, while you’re doing that afternoon debugging session a co-worker comes over and asks why the class structure is the way it is, so you’re looking at one piece of code and talking about a second one. Then your phone rings and it’s a call from your SO. Now all of a sudden you’re doing 3 completely different things at once. I don’t know about you, but I can’t do three things as well as I can do any of them.
One of the reasons comes from system thinking. When you think about things as interrelated systems you recognize that there is some level of interconnection between things, even if you can’t see it on the surface. And for true mlti-tasking, that interconnectedness looks something like
One estimate of a context switch is that 20% of a day’s time is lost to switching between projects. That means that if you’re working on 5 different projects (not tasks in a project) you might be losing 80% of your time to context switches. That’s a lot of time. To a first approximation, that’s about 1½ hours per switch. And the same amount of time to switch back.
That’s a lot of time, and I generally don’t have that much extra time in my day. So again, to a first approximation, unless you expect that external delay to take over 3 hours, you’re much better off finding something else in the same project to work on. Do a code review. Answer some related emails (leave the unrelated ones for later). Work on that design doc. There will still be a context switch, but it’s much smaller and will take much less time.
