Multi-Tasking Considered Helpful

Muti-Tasking Is Harmful.

In general, you should have people assigned to One Project for large blocks of time, you should group your bugs by category so a bunch can be fixed at once without a lot of re-setup time, and you shouldn't constantly change your mind about which task has higher priority over which other task.

But we do this all the time;  "We need combat fixes to show on the next rev!"  "We need those memory optimizations for the next burn!"  "We need, we need, we need..."

So is it really as bad as all that?

Joel Spolsky puts forth a situation where a guy is rotating between Task A, Task B, and Task C.  What usually happens in the real world is actually a stack:  guy works on Task A, the higher priority Task B supersedes that, and the higher priority Task C supersedes that.  Task C ends up done ASAP, Task B less so, Task A less-less-so.  You might get some wanker asking "Joe Coder started Task A two months ago and it's still not finished!" at which point you point out it was that or Task C and they shut up.

So, in short:  no, it's not really always as bad as all that.

Still, there's something to be said for not switching to a higher priority task if your current task is close to being finished.  In the long run that'll pay off.

Comments

[Greggman]

Hmmm, I seems like you missed his points

1) At least for him, he claims it takes him 6 hours to task switch. So, in your examples, A stacked by B stacked by C (A->B->C->B->A) is 2 task switches more than (A->B->C) or if we were as good as (or as bad as) Joel that would be 12 hours lost to task switching.

2) In his other example of switching back and forth with zero task switching time ABABABABABABAB vs AAAAAAABBBBBBB, if we switch to people instead of CPUs in the second case A will get done nearly twice as fast as in the first case. That means the rest of the team waiting for A to get done can get started using A much quicker again saving more overall time than the first case with all the people waiting for A and all the people waiting for B have to wait nearly the full amount of time.

I know it's not always that easy in the real world. For example on my team we had quickly implemented 32bit RGBA textures just to get something on the screen with the low-priority of changing that to 4bit quantized paletted RGBA textures later when we had time (since 4bit paletted textures run a zillion time faster than 32bit RGBA textures). Well, a couple of weeks later the other people on the team started discussing massively convoluted solutions to the problem of using 32bit RGBA textures. I guess they forgot it was on the list just at a low priority so I had to move it to a high priorty before they fudged up the entire tool chain with their convoluted solution. That same type of thing happened at least 2 other times. I guess that probably suggests communication on the team sucks but it was listed as a priority issue originally.

[Rohan Verghese]

I think Joel is discussing things at a lower level than you are. His argument is that 'during the course of one day, you should not switch tasks', which makes sense.

After all, in your example, you finish Task C as soon as possible. You do not alternate between working on Task C and Task B.