This study seems to be more concerned with rapid switching between two tasks, which they show incurs overhead. But I've noticed that almost universally, developers who have two major projects to work on, even if they alternate every other day, will not get as much done as if they do them sequentially. One thing I've seen time and time again is an entire team that is having trouble getting started on a new project after they've finished an old one. It can take weeks to get up to full-bore productivity on a new task again. The overhead of task switching can be huge.
Typically you see individual developers overloaded with two or more projects because of severe time pressure and understaffing. Sometimes I'll come upon a software team that has a single developer "working" on three projects simultaneously.
"Task switching incurs overhead," I say. "Why don't you have Bob do these tasks one after the other, instead of switching off during the day?"
"Oh, we would never finish in time then. All three projects must be done within one month. Bob could never get them all done in one month if he did them one at a time."
This just proves that the schedule is completely unrealistic. Despite the fact that the multitasking dramatically reduces productivity, they're willing to do it because it obscures the schedule. It seems like each of those tasks takes about a month. Do them in sequence, and three months will elapse. Do them at the same time, and it's possible to deceive yourself that only a month will elapse. (In reality, six months will elapse and one task won't even get done.)
More on firewalls: my latest idea is to buy an old Pentium 200 on ebay for $50, and use SmoothWall. Yeah, it's not as fun as buying $2500 worth of Sonicwall equipment, but it's sure going to be educational.
You’re reading Joel on Software, stuffed with years and years of completely raving mad articles about software development, managing software teams, designing user interfaces, running successful software companies, and rubber duckies.