The True Cost of Context Switching

Haoran Zeng

March 1, 2021

Context switching, also known as multitasking, is very common in our day-to-day life. Most SDE jobs require engineers to balance competing demands for their time and energy, and managers expect them to be able to handle multiple priorities.

Most of us would agree that focusing on a single task is more efficient than working on multiple tasks at the same time. However, an engineer seldom owns one project, engineers are required to do context switching and prioritize tasks as a part of their daily responsibilities. This situation motivated us to write this blog to help you better optimize your engineering processes.

As engineering management experts, we will use data to uncover the true cost of context switching and discuss an acceptable level of context switching for your engineering team.

‍We will be looking at cycle time to have an objective measure of the impact.

What is context switching?

Computers are good at multitasking. A PC allows you to watch videos while typing an email at the same time. While the CPU can handle multitasking, human brains cannot. When working on multiple tasks, we switched attention from one task to another.

What is the impact of context switching on an individual pull request?

We collected 224,039 pull request data from 2020 to analyze the impact of context switching on cycle time.

There are three common context switching behaviors for engineers:

Pull request context switching: an engineer started another pull requests while working on a specific one
Commit context switching: an engineer committed to another pull requests while working on a specific one
Comment context switching: an engineer commented on another pull requests while working on a specific one

We used these three conditions to identify whether a pull request was worked under context switching.

‍

Among the 224,039 pull requests, 86% of pull requests were handled under context switching. The cycle time of context switching pull requests is 223% slower than that of non-context switching pull requests.

The number of changed files is an indicator of the complexity level of a pull request. T-test results proved that the average number of changed files is similar. Thus, the complexity level of context switching pull requests and non-context switching pull requests is not statistically significantly different.

To figure out which context switching related activities are more impactful, we used a combination of correlation analysis and Random Forest feature importance plot to show the results.

‍

This plot indicates that all context switching activities can slow a pull request’s cycle time. Context switching comments and commits are the top 2 important drivers of slower cycle time. A higher correlation indicates that the positive relationship between a variable and cycle time is stronger. The variable importance provides a general intuition about the degree of importance of the activity on cycle time.

When we categorize context switching activities into different bins, we can see that as the number of context switching comments, commits, and self-created pull requests increases, the cycle time also increases.

Context switching activities make a pull request’s cycle time slower. Compared with non-context switching pull requests, context switching pull requests are, on average, 223% slower. Context switching comments and commits slows a pull request’s cycle time more than context switching self-created pull requests.

What is the impact of context switching on an engineering team?

Previously, we noticed that context switching activities dramatically increased the cycle time of individual pull requests. We also analyzed the impact of context switching on the team’s overall cycle time.

A very interesting trend can be observed between the context switching and a team’s average cycle time. The team’s average cycle time became very fast when 40% of the team’s pull requests are under context switching.

Unblock teammates! There is a tradeoff between an individual’s cycle time and the team’s cycle time. If committing and commenting on teammates’ pull requests help unblock them, you should do so. When a team only has 20% of context switching pull requests, the team’s average cycle time is about 4.5 times slower than that of a team having 40% of context switching pull requests. However, a team should avoid having more than 50% of pull requests under context switching.

Given that a certain level of context switching helps the team’s cycle time, we plot the relationship between an engineer’s average number of context switching commits and a team’s cycle time.

A gentle positive relationship can be observed between the number of context switching commits and the team’s average cycle time. Unless engineers are unblocking teammates’ pull requests, they should not contribute to others’ pull requests.

This plot shows the relationship between an engineer’s average number of context switching comments and a team’s cycle time.

Engineers should prioritize unblock others’ pull requests, but avoid getting into long discussions while working. We recommend engineers limit their pull request size as small as possible, small pull requests accelerate the code review process, allowing reviewers to leave fewer comments and engage in less context switching activities.

We also plotted the relationship between an engineer’s average number of context switching self-created pull requests and a team’s cycle time.

Engineers who worked on multiple pull requests simultaneously can also harm the team’s cycle time. We recommend engineers have at most one work-in-process pull request and have one pull request waiting for review. Anything above 2 context switching self-created pull requests would increase the team’s cycle time from 50% to 200%.