Nov 14, 2022
Software Engineering Management & the danger of Context Switch
The difficult balance of multitasking
How many times have you found yourself as a software engineer assigned to multiple tasks in parallel? And how many times have you complained about the inefficiency of your work in this context? However, it is so common to observe such a pattern even though it seems clear to be an anti-pattern.
A company tries to push more work to the limit with the same resources for cost saving. Clearly there is physical limit to this, but you will burnout long before you hit this limit due to the large amount of multitasking you are being asked to handle.
The idea of the “context switch” was introduced in computing as the process of storing the state of a process or a thread, so that it can be restored and resume execution at a later point, and then restoring a different, previously saved, state. This allows multiple processes to share the same CPU, and is essential feature of a multitasking system. Context switches are usually computationally intensive, and much of the design of operating systems is to optimize the use of context switches. Switching from one process to another requires a certain amount of time for doing the administration — saving and loading registers and memory maps, updating various tables and lists, etc. What is actually involved in a context switch depends on the architectures, operating systems, and the number of resources shared. This computer centric perspective can be dressed in the human space where the CPU is our software engineer and the several processe are the tasks assigned to her, causing the context switches and the multitasking.
It is well proven that context switches in computing are difficult to manage and are not granted to be optimal, so why should we think differently when applied to people? Even though as humans we can handle better these situations than machines, we still experiment the same problems. When we have to switch from one task to another, we have to freeze what we are doing in a way that we can later easily restart, so we have to clear our mind and enter a new topic possibly restoring all the previous information left by us and/or by others. All this management takes time, and productivity (roughly understood as the time to close the task) clearly decreases and the drop is about 15% — 20% per context switch. So with few changes of subject you can destroy the productivity and the illusion of doing more with the same people will be a boomerang, producing less than just doing one thing.
Should we totally deny multitasking? Not at all from my point of view, but it needs to be handled carefully. In a daily routine it is sometime helpful to change th esubject, especially if you are stuck or exausted on your current one. It can also be satisfying to manage different topics because you can address different challenges and learn/improve different skills. There is also the pesonal component, where everyone struggles more or less in the context switch and you have to be aware of it as a single contributor and also as a manager. Allocating many tasks to the wrong people will have the double worst outcome: no solved tasks and a burned out person.
My last tip is: show a red flag as soon as you see there is too much to be done on the table for your team pushing for a high level of multitasking. In my experience, tackling so many topics (or even too many products) in parallel has never been a good choice.
