About Petri Kainulainen

Petri is passionate about software development and continuous improvement. He is specialized in software development with the Spring Framework and is the author of Spring Data book.

The Cost of Context Switching

I have always thought that I am good at multitasking. That is why I believed that I don’t have to pay the price associated with context switching (or task switching).

This week I realized that have been wrong. I am not very good at multitasking and context switching is much more expensive than I thought.

The reason for my mistake is simple:

I hadn’t been interrupted nearly as often as I thought.

Why Context Switching Is So Expensive?

The effects of context switching are painfully familiar to me:

  • If I am working on something, and I have to start doing something else, it can take ages before I am actually working on the new task.
  • Because I have to switch contexts multiple times a day, I feel that I cannot get anything done (often this isn’t just a feeling).

Joel Spolsky explains the reason for this:

The trick here is that when you manage programmers, specifically, task switches take a really, really, really long time. That’s because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming. A programmer coding at full throttle is keeping zillions of things in their head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code. If you send that programmer to Crete for a three week vacation, they will forget it all. The human brain seems to move it out of short-term RAM and swaps it out onto a backup tape where it takes forever to retrieve.

The interesting thing is that the price of context switching isn’t constant. It depends from the complexity of the new task.

If the new task is so simple that even a monkey can do it, the price is very small. Typically I can just finish the new task and continue working on the old task without losing any time. The reason for this is that I don’t have to clear my short-term memory because the new task is so simple.

On the other hand, if the new task isn’t trivial, the price is very high. I have to clean my short-term memory and load the information which I need to finish new task. After I have finished the new task, I have to clean my short-term memory and load the information which is relevant for my original task. In other words, I have to pay the price twice!

How big the price of context switching is? I assume that this depends from the person but I have noticed that it can be anything from 5 to 30 minutes per context switch. This is insane because if you have to switch contexts multiple times per day, you waste a lot time and consume a lot of mental energy.

Finding the Middle Ground

Because context switching has a high price and it is mentally draining, we should avoid it at all costs. However, this is easier said than done because “real” team work (agile methods) is an essential part of modern software development, and I think that it has clear benefits which shouldn’t be overlooked.

In other words, we must find the middle ground between collaboration and heavy lifting.

We have to respect our own time and the time of our team members, and the easiest way to do this is to follow these rules:

  • Do one thing at the time. If you have to finish two tasks, finish the most important one before starting the second one. This way you can finish at least the most important task. If you try to finish both tasks, you might not be able to finish either of them.
  • Use asynchronous communication. The next time you have a question, don’t interrupt the person who can answer to your question. Instead you should use asynchronous communication tools such as IM, email, or some other collaboration tool. This way the person can answer to your question when he has got the time to do it. Also, make clear that your team members must treat you in the same way. If the shit hits the fan unless your question isn’t answered right away, you can interrupt the person who can help you out, but remember that this person pays a heavy price for answering to your question.
  • Ensure that you are not interrupted if you need to get something done. If you are working on an important task, you must have the possibility to finish it without interruptions. Create a way to signal to your colleagues that you don’t want to interrupted. If your colleagues don’t respect this, you can work in your home office until you have finished this task. Also, remember that this is a two-way street.
  • Accept that you cannot do everything, and make sure that your employer accepts this too. If your role is to help other developers on a regular basis, don’t feel bad because you feel that you cannot get anything done. Make sure that you don’t take any high priority tasks because you cannot give them the attention they deserve.

Some of this advice might seem anti agile. The problem is that the rise of agile software development methods has created a mental image which encourages us to collaborate all the time. This mental image will destroy our productivity and we shouldn’t embrace it.

Instead, we should accept that there is time for collaboration and time for doing the heavy lifting, and we cannot do them both at the same time (unless we are doing pair programming or mob programming).

Reference: The Cost of Context Switching from our JCG partner Petri Kainulainen at the Petri Kainulainen blog.
Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

Leave a Reply

seven × 5 =

Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books