Multitasking adds to the task list (while diminishing avialable productive time). No wonder it’s trend!

Keith Ray posts this snippet of conversation:

Ron Jeffries posted his email conversation with Jon Eaves on XP mailing list in “Bug tracking vs user stories”

[ jon ]

“Projects that have developers working on multiple simultaneous projects have a 30% higher defect rate than projects with developers assigned specifically to it”

[ ron ]

Fascinating if true.

[ jon ]

I don’t remember the actual number, this is again from a previous life, but there was a higher defect incidence rate. We stopped this practice (or at least attempted to minimise it) and life was better for everybody.

Ok. So context switching uses tons of time, reducing productivity, and it also leads to higher defect rates.

Either those defects get shipped, or the poor harried programmers use their few remaining shreds of productive time to fix them. (It would be interesting to see what the Fault Feedback Ratio is in cases like this). How do folks make forward progress?

The other day I overheard a conversation between an overworked developer and her manager. The manager had just added on another task to the developers overfull plate. When the developer protested, the manager said “Well, you’ll just have to multitask!”

I cringed. Directing staff to multitask rather than setting clear priorities and focusing on the most important initiatives is an abdication of management responsibility. Period.

(And the manager may not have known:

— how to prioritize

— how to determine what the top priorities are

— how to say “No”

— how to get out of fire fighting mode

— how to sequence work

— the costs of multitasking.

But that’s another story.)