Context Switching and Multitasking
Being human, we can’t multitask. Contrary claims are occasionally made, and while it may well be that there are a few select people who are capable of a higher degree of multitasking than others, the majority of us can’t do this well over an extended period of time, and shouldn’t. It wears us out.
Having said that, very few of us are working on one and just one thing at a time. Instead, we switch between projects, sometimes even between tasks, while they are running simultaneously. Given the previous paragraph, that’s at odds with how we tick.
So is being worn out just a natural consequence of being human, then? I don’t think so. If you would humour some not-backed-by-psychological-research musing …
Context switches are a frequent pain for an engineering team, because every time a switch happens, the team will have to rewire the mental models they are using and working with. While I will be the first to freely admit that avoiding such switches altogether would be great, I also have to face the reality of a team building a next-generation product (that, until ready, can’t be sold) while maintaining the current one (that pays the bills).
What, then, would be a good way of keeping the negative impact of switching between the two at bay? Rather, when is the negative impact the highest? This is when the context switch happens in mid-flight, when the focus is sharp and the work well under way and productive. In such a situation, making a sudden switch to an entirely different code base will be detrimental.
It follows from this that the best moment for switching is when a task is completed. At that point, a decision about whether to continue with the next task in the current project, or whether to switch to a task in a different project, can be consciously made, and the negative impact of context switching will be lower. It will never be zero, because different knowledge and mental models will have to be (re)built.
(Once more, reality may have a different opinion sometimes: if a sufficiently severe bug rears its ugly head in a project different from the one that currently has focus, it will rightfully demand immediate attention. That should be the exception.)
The two models described above resemble different programming models in parallel programming. On the one hand, there’s classic multithreading with its preemptive multitasking model, where the operating system commands when control can switch between threads. On the other, there’s coroutines, which specify yield points, at which context switches are allowed to happen. This is also known as cooperative multitasking.
I believe that engineering teams - unavoidably facing the risk of context switches - would benefit from a cooperative multitasking approach. They will consciously prioritise their backlogs to allow for context switches at points that make sense. This is also relevant for working on bugs, whose appearance on the scene is not predictable. Addressing a bug with less than house-on-fire-incident severity can be scheduled in a smart way, not for immediate attention, but also not too far in the future, depending on its impact and the effort needed to address it.
Ultimately, this is all about giving teams a healthy degree of control over when they perform context switches.
Tags: work