For some time, I've been a little uneasy with Dale Emery's article on [[http://www.dhemery.com/cwd/2005/11/multitasking.html|Multitasking and Conflict]], not because what he says is wrong, but because I don't believe it tells the whole story.  Don Gray's [[http://www.donaldegray.com/blog/archives/03-01-2006_03-31-2006.html#50|critique]] of Johanna Rothman's article on [[http://www.ayeconference.com/Articles/ContextSwitching.html|Context Switching]] was the trigger to write up a few of my own thoughts.

You see, I greatly respect all three of these people, and I agree with what they all say.  But there's more to it than that.

== Microprocessor interrupts and people ==

I started in software development writing code for 8-bit microprocessors.  Most processors support what's called an ''interrupt'' which triggers a context switch and is used to support multitasking.  In the simplest cases, interrupts come from external hardware wired to a port of the microprocessor, but later, more sophisticated processors added the ''software interrupt'' where the trigger can be from some code running on the microprocessor.

When an interrupt occurs, the processor pushes the contents of the registers (''small bits of special purpose memory within the processor''), including the one that points to the next instruction to be executed, onto the ''stack''.  It then starts executing code at a location appropriate for that particular interrupt until it encounters a "Return From Interrupt" instruction.  This instruction marks the end of the ''interrupt service routine'' and the processor pops the register contents off the stack back into the registers and resumes operation as if nothing had happened.

This is a very efficient and deterministic process.  People, unfortunately, can have a little more trouble making such a context switch and then switching back.  What can go wrong?  As [[http://www.donaldegray.com/blog/archives/03-01-2006_03-31-2006.html#51|Don says]],

 ''Restating George's thought, it's not the context switch out that's difficult. It's the context switch back. Unlike the wonderfully linear microprocessor, we humans tend to be incredibly nonlinear, tightly-coupled, loosely cohesioned (if you know what I mean) creations. This applies even to those of us who believe we are linear and straightforward.''

I think he's absolutely right about the context switch back, but that he underplays the context switch out.  I've been interrupted while in deep concentration and, while I turned to answer the interruption, was unable to let go of the previous context enough to concentrate on the new context.  I was able to let go of the previous context enough to lose that thread of thought, however.  This is the worst of all possible worlds.  Not only have I paid the price of being interrupted, but the interruption didn't achieve anything positive.

And Don doesn't even mention the ''hysteresis'' that we humans exhibit.   After we finish the "game of trying to find where we were, why we were there, and what we were doing," we're not really in the place where we were.  Like a piece of metal that been bent, and bent back, we are not unchanged by the process.  The place we find to resume our previous context may be an OK place for making progress.  In rare cases it may even be better than where we were.  Most of the time, though, we've lost some subtle insights that had not yet been expressed in words (or code).  We've lost the ''flow''.

== Interrupt mask ==

Sometimes it's very important that a process not be interrupted in a ''critical section'' of code.  To prevent this, an ''interrupt mask'' is used to mask off, or disable, interrupts.  When the mask is turned off, and interrupts reenabled, then an interrupt that occurred during the critical section will be notices and serviced.

For people, such a critical section might be a period of time where they get into the [[http://en.wikipedia.org/wiki/Flow_(psychology)|flow]] of creative work.  How can they mask interrupts while in this state?  Well, like a microprocessor, it's important to mask them before entering this state.  Perhaps by closing the office door before starting the work as a signal that you're not to be disturbed.  Perhaps by teaching others to recognize the signs that you're in a critical section, and not to disturb you during those times.  ''I'd love to hear your ideas on masking interrupts.''

It's generally a good idea to reenable the interrupts in a reasonably short time so that important things aren't delayed too long.  (If they weren't important, they probably shouldn't be assigned to interrupts.)  In a processor, if interrupts aren't re-enabled, things just don't get done.  People are more resilient, though, and will re-enable interrupts on their own if feel it's important.  If your office door is always closed, some people will cease to take it as a sign that you shouldn't be interrupted.  You will have lost control of your interrupts, again.  People will interrupt you for low-priority things, but also some high-priority things just won't get done.  Not everyone has the same threshold of when the interrupt mask should be ignored.

== Non-maskable interrupt ==

Sometimes the interrupting task is so important that you don't care if you interrupt even a critical section.  For this, you use the ''non-maskable interrupt''.  As it's name implies, the interrupt mask doesn't affect it.  The non-maskable interrupt may be used for things like a reset button.

What if the building catches on fire?  You'd want to be notified, even if you had your door closed and were working on something very creative and important.  Survival trumps creativity.  This is a non-maskable interrupt.

== Multiple interrupt priorities ==

The first processors tended to have only a single interrupt.  For simple things, this might be enough, but people eventually developed more sophisticated designs to service more sophisticated needs.  A typical implementation supports multiple interrupts with multiple ''interrupt priorities''.  As a general rule, a lower priority interrupt may not interrupt the execution of a higher priority interrupt.  This is accomplished by automatically setting the interrupt mask to that level, masking lower priority interrupts but not higher priority ones.  The interrupt service routine may, however, unmask lower priority interrupts after it has finished the most important part of its work.  Or, it may mask all interrupts while it accomplishes a critical task.

=== How might people employ such flexibility? ===

If you're mowing the yard, you might not want to be interrupted by a request to wash the dishes.  Nor would you want, if you were washing the dishes, to be interrupted by a request to mow the yard.  These two tasks are roughly equal in priority and urgency, and it's not worth the inefficiency and irritation of a context switch in the middle of either one of them.  If you're juggling these priorities yourself, you might choose to interrupt washing the dishes and start mowing the yard if you heard a weather report that rain was on the way.  The urgency of mowing the yard increased, and with it, the priority of the task.

If Ed !McMann rang the doorbell to deliver a million dollar check made out to you, however, you might gladly drop either task to greet him.  Or if your child was running toward a busy street, you wouldn't hesitate to interrupt your task to stop him from darting into traffic.  Either of these interruptions is a higher priority than washing dishes and mowing grass.

=== ContextSwitching from the point of view of the interrupter ===

Now look at the situation through the eyes of Ed !McMann.  He's got a million dollar sweepstakes check to deliver, and that's his only goal at the moment.  He's not concerned with your grass getting mowed or your dishes getting washed.  So, he just rings the bell and waits for a response.

A peer or coworker might consider ongoing relationship between them and you.  Assuming that relationship is on good terms, a peer probably doesn't want to annoy you with low priority interruptions.  But a peer probably also knows you well enough to be able to judge the approximat priority of your current task.  If you're just "shooting the breeze" over the fence with the neighbor, then a request to mow the grass or wash the dishes might not be out of line.

A subordinate is in much the same situation, though generally with more reluctance to interrupt.  You might have to make a special effort to encourage interruption in some situations.  A captain of a vessel offshore, for example, will generally ask the crew to summon him if there is any question as to whether the situation warrants it.  Better to be safe than sorry, in that situation.  You might want to set different limits in your own life.

Now, we finally come to the situation that Johanna describes.  What if a superior, your manager, perhaps, has a task to assign?  The manager could approach the situation in the same manner as a peer, trying to judge if the current task is lower priority and an interruption is justified.

More often, in my experience, the manager acts like Ed !McMann, barging in, but not with that million dollar check made out in your name.  Why would they do this?  Several reasons come to mind:
 1. ''They don't notice what they are doing.''  They're absorbed by their own concerns, and don't see the big picture.
 1. ''They don't understand the consequences of what they're doing.''  They don't realize the cost of their actions, and how it makes their projects fail.
 1. ''They don't care what they're dong.''  They're working from the wrong definition of "superior" and think that means your purpose is to do their bidding, no matter how arbitrary.
 1. ''They're not competent to manage.''  They can't assign priorities to the tasks that need doing.

== Time slicing ==

''ToBeWritten  Scheduled multitasking. Don's swapping CDs.  Johanna's iterations.  Dale's conflict avoidance.''

== Bibliography ==

 * Dale Emery's article, [[http://www.dhemery.com/cwd/2005/11/multitasking.html|Multitasking and Conflict]]
 * Johanna Rothman's ''Better Software'' article on [[http://www.ayeconference.com/Articles/ContextSwitching.html|Context Switching]]
 * Don Gray's [[http://www.donaldegray.com/blog/archives/03-01-2006_03-31-2006.html#50|response to Johanna's article]] now [[http://donaldegray.com/tiki-view_blog_post.php?blogId=1&postId=29|moved here]]
 * Don Gray's [[http://www.donaldegray.com/blog/archives/03-01-2006_03-31-2006.html#51|response to my post]] now [[http://donaldegray.com/tiki-view_blog_post.php?blogId=1&postId=30|moved here]]
 * Johanna Rothman's [[http://www.jrothman.com/weblog/2006/04/convincing-management-that-context.html|followup]]
 to Don's and my comments
 * [[http://donaldegray.com/tiki-view_blog_post.php?blogId=1&postId=36|Further thoughts]] by Don

see also:
 * My blog post on [[http://blog.gdinwiddie.com/2006/12/17/agility-and-context-switching/|Agility and Context Switching]]
 * Johanna's thoughts on the [[http://www.jrothman.com/weblog/2006/11/costs-of-multitasking.html|Costs of Multitasking]]
 * Tony Rizzo's [[http://www.pdinstitute.com/soapbox/2004/11/19-multitasking-is-costing-billions.html|Multitasking Is Costing Billions]]
 * Lidor Wyssocky's [[http://blog.qualityaspect.com/2006/03/21/multitasking/|Multitasking]] entry in the Hitchhiker’s Guide to Software Development
 * Kathy Sierra posts on [[http://headrush.typepad.com/creating_passionate_users/2006/12/httpwww37signal.html|Creating Passionate Users]]:

 ''...the one thing that makes most of us the happiest... being in flow. Flow requires a depth of thinking and a focus of attention that all that context-switching prevents. Flow requires a challenging use of our knowledge and skills, and that's quite different from mindless tasks we can multitask (eating and watching tv, etc.) Flow means we need a certain amount of time to load our knowledge and skills into our brain RAM. And the more big or small interruptions we have, the less likely we are to ever get there.''
  * also see her posts [[http://headrush.typepad.com/creating_passionate_users/2005/03/your_brain_on_m.html|Your brain on multitasking]] and [[http://headrush.typepad.com/creating_passionate_users/2006/03/multitasking_ma.html|Multitasking makes us stupid?]]
 * Frank Patrick [[http://www.focusedperformance.com/2006/12/multi-tasking-or-not.html|says]]

 ''Bad multi-tasking is the interruption of one task, started, but not completed, to perform another unrelated task for no reason other than to get the second task started. If taken to the (usual) "extreme", bouncing back and forth between uncompleted tasks results in no benefit for either; indeed, it results in delay of completion of both.''

 ''Progress is not acheived in just getting something started, or even paritally done. It only really occurs at the completion of the task when some other resource ... can make use of your output.''