Thread Context Switching Isn't Just Bad for Processors
As most developers know, a context switch is when a processor changes out the thread it is working on for another. Usually this is in response to the fact that the thread they were working is waiting on something, so it can switch off to a thread that has some immediate work. By doing this we can greatly increase the throughput of a system. But what happens if we have tons of threads and constantly have to switch? Well, that’s not exactly ideal because it means we have to load up the data dealing with that thread, figure out where we were, and then continue until we reach the next switch. Too many context switches and your throughput starts to actually suffer and nothing gets done.
This isn’t just true of computers. A colleague, Drew Marston, and I were talking about the cost of context switching for developers (or really anyone). When you are focused on a task and someone interrupts you, or if you have to switch contexts because you now need to focus on a new task, you will lose time. I don’t think anyone can argue that point. In some cases the switch is helpful. If you reach a point where you have to get input from the product owner, or you are waiting on another developer to complete an interface, you can switch over to another task. But if you are plugging along quite well when someone appears to derail your current flow, that can be quite damaging to your throughput.
Drew sent me a link about how a study was done on interruptions for doctors in an Emergency Room. The study is quite interesting (and entirely mortifying). Here is the link: http://www.cnn.com/2010/HEALTH/05/12/doctors.interrupted/index.html?hpt=C1. One statistic: doctors that are interrupted were found to NOT return to the task that was interrupted 18.5% of the time. Man, I really hope that task wasn’t reviewing my CT Scan or telling the nurse to get me more pain medication, though it would explain a lot about the last ER trip I made.
I’m not after the shock factor here, but rather I want to point out that this isn’t just over-burdened CPUs or Doctors that suffer from this context switching. If you have developers working on many projects simultaneously, they will suffer the same issues. One of the goals of an agile methodology is focus. You have small iterations that focus on providing a small set of features. These are easy to digest and easy to focus on. This is a great strength of the iteration, or sprint, mentality in my own opinion. It allows developers to focus on a small set of features and just bang them out.
If you are a developer and you get assigned ten projects all due around the same time, take the article above to your manager. Discuss the cost of constant thread switching and see just how much your throughput is actually suffering. If you are a manager, I’d like you think about how many different tasks you’re asking your developers to do. Think about the cost of task switching and see if there isn’t a way that you can help provide better focus.