Context Switches are Expensive

[size=small]No computer processor can do multiple different jobs at the same time - there is no real multitasking going on. Instead a processor does one job after another.

When you see programs working in two different windows at the same time, it's just because the processor is doing a piece of work for the one program running in that window, doing a little bit for the other window in the background, doing a little bit for the operating system, again doing a little bit for that window in the foreground and so on. Suddenly a hardware interrupt requires CPU team and the current task will be interrupted.

A CPU constantly switches its context to simulate a parallel processing to the user. However these context switches cost quite some performance. The processor must load the working data into its internal memory, continue working on a chunk, store the current working data to the RAM, figure out, which chunk has to be processed next, load its data, continue working... and so on. The real computation time is wrapped by a lot of overhead.

A Human Brain is a CPU

Nothing new to computer pros - so why am I telling you that? Because humans do their work just as processors and both face similar problem: How to complete tasks while being most productive as team? This article shows some strategies on how you can deal with context switches in an engineers work environment while still being available to your team mates when they have questions and to keep them and you running. It's mostly about the right use of communication and that's what this article is focusing on.

For humans a context switch can be extraordinary expensive. For this article I am focusing on a environment like my daily work place: A cube farm full of software developers that do their best to concentrate on design and coding while battling with their IDEs. A cube farm that is more open, i.e. people are not sitting in a four walled cube and meet each other for lunch or random meetings. I am talking about team performing agile development practices, where active team communication is encouraged or even required.

Researches have found that interruptions during a task that requires a high level of concentration may cost up to 15 minutes until the same level of productivity and concentration compared to before the interruption can be achieved. This regeneration period of time is depending on the individual engineer of course. Some can cope with such situations very well, others can not. If you think you are one of the first sort of people you may stop reading here. If you are the one that suffers from context switches you may be able to get some hints from reading this posting.

Eliminate Interruptions

Unfortunately in a software developers work environment there are numerous events that do their best to keep the developer from maintaining this high concentration level.

So the answer to this is so simple: Eliminate source of interruptions. Do not start your mail program, turn off your phone then draw a red line on the floor around your desk and hang up a yellow sign reading “Trespassers will be shot”. Finally no more disturbance and shortly you will be the most productive engineer in your team – and the most hated and isolated and sooner or later you won't have any problem with your personal productivity anymore: Congratulations! Mission accomplished! But you don't have a job anymore.

Seriously, isolating yourself from the team is no option. Let's face this: Your own productivity and your ego do not matter. The only factor that matters is the productivity of your team as a whole. Not you are responsible for delivering a new software product in time, but your team is. If you isolate yourself the team will just loose a team player.

The Team is Important – Not You

So work with the team and help your colleagues when they need help as you will certainly not be the genius who never needs help on your own. Your teammates do not consult you just to bug you. They have a problem and need to find a solution to be able to continue with their own work. If you don't help them, their productivity will suffer if no one else can answer their problem. This will decrease the productivity of the team. A team is only productive, when everyone can do his work as productive as possible. Therefore always be available if someone needs you as you and help as soon as possible to keep the productivity of your teammates up.

But wait... we have a serious conflict here.

If you're always available you never can plan your own work. You must expect to work like a processor on a server running on full capacity. Always be available for requests and accept context switches at a high frequency. But you are a human and as we have learned you need much longer to regenerate from a context switch. The longer your personal context switch regeneration time and the more frequent interruptions occur the less your personal productivity.

Unfortunately there are numerous of events in a modern work environment that will try to spoil your productivity:

* A new email has been received and begs to be read and answered.
* The RSS pops up and informs you of a new interesting posting by your favorite blogger or a new article on slashdot.
* A colleague wanders by and dares to ask you a question.
* A meeting starts.
* You get a phone call.
* Colleagues are discussing something at the neighbors table. You can't overhear that and suddenly you are participating in this discussion.
* You are stuck with your current task and need help from a colleague before you can continue.

Frequently I read the following tip: Reduce the time for reading and answering emails to a short period of time. Once in the morning and once in the afternoon. While this may work for old fashioned work environments, where every single individual is working on his own for the most of the time and where email is not very important and people did not yet learn to work with it this will not work for a software development team. It will even make things worse: When your colleagues notice that they will have to wait longer for an email reply from you, they will either come in person to your desk (and ignore the red line on the floor) or they will call you and you won't have a change to ignore this for more than a minute. A context switch might be necessary right when battling with an extremely difficult piece of code like trying to figure out, why the complex recursive call to your method did not work as expected.

Get Rid of Background Tasks

So forget this for email. But have a look at the list above. There is one item that will work perfect for this strategy. Turn off your RSS reader. Do not keep it running in the background. No one expects a response from you and the importance of reading news and blogs is very low. Anyway I don't say to get rid of RSS readers. RSS readers are very efficient for staying up to date. You don't have to visit web sites just to see if there is something new (especially my blog would be a waste of time, since there is not much happening here – but if you would ignore it, you wouldn't read this article). But do not keep them running in the system tray and especially turn of pop up notifications for new items.

In summary: Get rid of events that do not require your response, while you have more important work to do. In the digital world a virus scan on a server is not scheduled during service hours, when the server needs to be as responsive as possible.

The Email Problem

Let's get back to email: How can we reduce the context switches with regards to email while keeping my colleagues from wandering by or giving me a phone call? Email often takes a fair amount of time to answer. An email might be just SPAM so the context switch was absolutely useless. Sometimes email contains read only information, sometimes a colleague just needs a short answer. Another email may contain a request to send a file and then there is the email from your boss, where he need a presentation – in the worst case for the meeting in the afternoon. Welcome to the world of Dilbert.

So the problem with email is that you never know the impact of a new email on your current task: Is it just an information note that could wait until the next day or does it require immediate response within several minutes? The problem is that you have to read the email first, before you know its urgency. Therefore most people have enabled pop ups or at least an icon in the system tray that notifies the user at once an email has been received. Then these people can immediately read the mail and check how important it is.

“Hm... that mail is not very important right now, but I can read it later. Hopefully I won't forget that” - in this case flag the email (Mozilla Thunderbird has a great feature that allows to apply customizable tags to each email like Gmail) or leave it as unread. Now get back to work and don't run into the next trap:

“OK... that mail was not very important right now, but wait there is another unread email... Let's check that out” - and soon you spent several minutes on reading and answering a couple of emails, when you have planned to just do a quick check on a single new email. This is the worst case of a context switch. The longer an interruption the longer your regeneration time to get back to work on the interrupted task.

So the real problem with Email is its uncertainty. You cannot plan the impact of an email on your current work until you have read it. But then it's to late. The disturbance in the force has already occurred. The recommended solution by so called experts I explained above sounds not so bad. So let's step into that direction by just saying that email is the communication media with the slowest response time. But keep it flexible. Respond as time allows.

Do a Context Switch When You Want

When a software engineer is working on a task it is never done at the same level of concentration. There are even a lot interruptions during a task without intervention from the outside:

* You must wait for a compile to finish.
* The application server must be restarted and that takes several seconds.
* You have to update your local repository from the subversion server.
* The IDE has crashed. You have to wait until it has restarted. You may have to reopen the files you were working on. If you were in the middle of a debug task you have to restore every single step until you are where you were, when it crashed.
* You just finished a very tricky piece of code and need some minutes off to relax and work on something else.

So every task is naturally chunked into smaller parts by these interruptions. Let's call them natural interruptions.

These are perfect occasions for a planned context switch. So far I always wrote that Context Switches are bad. But you cannot afford to do no context switches at all as already described. And you are just a human, not a computer. Your brain cannot work on the same task for a long time at the same level of concentration. Face it: You cannot get rid of context switches so learn to live with them. An intended context switch is much better than an unplanned and immediate context switch, when beeing in the middle of a complex task like a phone call that requires your immediate attention.

This is like writing a Java Program. When you write multithreaded code and a method shall be exclusively executed you write a synchronized block. No other part running in the same virtual machine can take the JVMs attention and disturb the flow of the code within the synchronized bock. After the synchronize block you allow other code to continue. Until then the synchronized block is executed exclusively unless the operating system kills the JVM.

Well, how does this help us with our Email problem? In generall\ you can judge on the impact of a natural interuption very well. You know how long a compile task last or how long a subversion update lasts. If you think that you have some minutes and you feel that a context switch does not hurt much do it now and look for your email. Do what is necessary: Write replies, compose a email, react to smaller tasks as appropriate and then return to the main task you where working on previously. Handle email, when you want to. Don't let Email interrupt your work.

That said you should already have understood that any form of active email notifications is inappropriate: Switch off that nasty pop ups and get rid of system tray icons. Although a quiet system tray icon is far better than a pop up, it is always visible and sooner or later you will look at it. And when you see that a new mail has arrived you become curious and then it's too late. When you have disabled that you will automatically forget your email for a while and even can close the mail program and give some memory and performance to your IDE (your CPU can safe another context switch to download new mail and analyze it for SPAM). Soon you will answer emails just when it is right for you. It's still good enough to have a response time for emails of up to 2 hours. That should be acceptable to every email for which email was intended.

Email is intended for exchanging information that is valid for some time. Or for requesting an answer that is not needed immediately. Email is not intended for urgent questions for which answer a team mate needs to wait until he can continue his task. Or requests that need a response soon like asking someone to come to his desk or join an ongoing meeting. Your teammates can still come to your desk or give you a phone call. And the need for that is not seldom - hopefully. It may be disturbing sometimes, but be honest: If's always good to have the feeling that your team mates need you and it always gives you a good feeling, when you were able to help a team mate successfully. However phone calls and personal attentions directly at your desk are always immediate interruptions. You have to respond within a few seconds.

There is a big gap between the response time of email of up to some hours and phone calls or someone requesting your attention in person of a few seconds.

Filling the Response Time Gap Between Email and Talking

This is where Instant Messaging jumps in. IM is perfect for intermediate but unobtrusive communication. Give your colleagues some seconds to finish their current work until they feel better for a context switch until they respond.

Unlike with email, the response time should be within several minutes. So do not disable the notifications of a IM program. However you may need to play a little bit around until you'll find the right notification form for you. One that does not disturb your work for some minutes, but still a method that prevents you from missing new messages for several minutes. Depending on the IM software there are various forms of notifications. From a simple blinking icon in the system tray or a flashing task button on the task bar to flashy On-Screen-Notifications. Most IM have a couple of configuration options here. For me the calm bubble of KDEs Kopete works best. An animated system tray icon is not enough for me, while a flashing task bar is to obtrusive.

Kopete has received a new message and shows a preview in a calm bubble.

The key to using IM messages productively is to have an agreement with your colleague, when to use it and when not. In general IM should not be used for sending important information that should be remembered or for informational message that do not harm to be read some hours later. In this case email is the media of choice. You also should not use IM messages for discussions. Discussions are better done on either the phone or face to face. But IM messages are great for short questions that can be answered easily like "Where can I find the file xyz?". Or use IM to "announce" a bigger context switch like "I have a serious problem here. Can you come to my desk" or "Do you have some minutes for discussing this new feature?".

Image how would you ask for the location of a file that you need without IM? Via email the answer could take several minutes, even some hours. So you will go to your colleague and ask him. So he can tell you the URL... Oh you can't remember long URLs? OK, he will send it via email. So you showed up at your colleague desk, forcing a sudden context switch for him but he still has to send you an email, since you need the data in a electronic form. So IM has a big advantage here.

However beware of the chatting pitfall. Do not use IM as a replacement for a chat, when you need to discuss something. If you feel that a conversation takes several messages, stop the IM conversation and visit your colleague to discuss this face to face. This is much more productive plus a IM conversation always bears the danger that your conversation partner can be easily misunderstand you. And IM is not a replacement for real world social contacts ;-)
So back to the context switch: An IM client can give your colleague some seconds to finish the harder part of the task he is currently working on. As a consequence do not hesitate to contact your team mate sitting right next to you via IM. It may be much easier to simply talk to him. I am not kidding here, although this might sound as a plot for a joke where a husband sends a SMS to his wife to give him the salt shaker. It's about interrupting your colleagues workflow in a polite and respectful way. Your team mate is not eating is breakfast, he might be concentrating on a tricky part of code.

If you still think that Instant Messaging is not important for a company have a look at Gartners Hype Cycle about Emerging Technologies for 2007 and have a look on the very right. Yes, there in the area of the Plateau of Productivity.

Wrap up

To put everything short:

* Use email for sending information which is valid for a longer time or which requires a response within some hours. Do not use notifications for emails, as emails typically will interrupt you for several minutes.
* When sending a short question use IM. Also use IM, when you need to discuss something with a colleague to announce the context switch to him. Use a form of notification that is appropriate for you but allows you to respond withing a few minutes.
* Visit a colleague or use the phone after you've announced it via IM or you have noticed that IM leads you to a lenghty chat. If it is very urgent, phone or visit your team mate directly, but keep in mind that you might interrupt him in the middle of a very tricky task that requires all his attention and would mean several minutes of getting back into it after you've left.

So, that's it. Hope this can help you a little bit and I have inspired to discuss this with your team. If you have done that I would love to hear some feedback from you.

And now stop reading and continue with your work.[/size]