In a computing system, a context switch occurs when an operating system stores the state of an application thread before stopping the thread and restoring the state of a different (previously stopped) thread so its execution can resume. The overhead incurred by a context switch managing the process of storing and restoring state negatively impacts operating system and application performance. This blog post describes how DevOps ameliorates the negative impacts that "context switching" between projects can have on a software engineering team's performance.

In the book Quality Software Management: Systems Thinking, Gerald Weinberg discusses how the concept of context switching applies to an engineering team. From a human workforce perspective, context switching is the process of stopping work in one project and picking it back up after performing a different task on a different project. Just like computing systems, human team members often incur overhead when context switching between multiple projects.

Context switching most commonly occurs when team members are assigned to multiple projects. The rationale behind the practice of context switching is that it is logistically simpler to allocate team members across projects than trying to have dedicated resources on each project. It seems reasonable to assume that splitting a person's effort between two projects yields 50 percent effort on each project. Moreover, if a team member is dedicated to a single project, that team member will be idle if that project is waiting for something to occur, such as completing paperwork, reviews, etc.

Using our computing system metaphor, this switching between tasks is similar to the concept of multi-threading, where if one thread blocks the process for some reason, other threads can perform other work, rather than waiting for the first thread to unblock. If all work was assigned only to the first thread, progress is much slower. While multi-threading may be sound reasoning in computing systems, the problem is that human workers don't always get a nice 50-50 effort distribution. Effort is thus lost to context switching, and productivity may drop precipitously as the worker's effort is spread across more projects.

In the above graph based on data from Quality Software Management: Systems Thinking, a team member with one project is able to devote 100 percent of his or her time to that project. A team member with two projects does not yield a perfect 50-50 split. The team member actually yields about 40 percent effort per project because of the amount of time (roughly 20 percent) needed for context switching. In other words, switching between projects requires an operational overhead for the team member to figure out where he or she left off, what needs to be done, how that work fits in the project, etc. Once a team member is assigned five projects, his or her ability to contribute to any given project drops below 10 percent, with 80 percent effort being lost to switching between project contexts.

The efforts lost to context switching are not just time, but quality also suffers. In particular, context switching can increase buggy code committed, unavailability of team members, and missed tasks, which require additional effort from team members to repair the problems. Joel Spolsky compares the task switching penalty for computers and computer programmers:

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 [sic] 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.

How DevOps Can Help

DevOps practices can help guard against some of the pitfalls of context switching, as well as alert the team when context switching is impacting product quality and team productivity. By leveraging continuous integration, any build failure will alert the team members when their contributions are impeding application or feature development. Likewise, automating the assignment of code reviews can insure code committed meets proper style and security standards.

Regular communication between team members is critical, especially when balancing work between projects. Without clear, structured avenues of communication, problems associated with context switching will quickly fall through the cracks. Daily stand up meetings and utilizing enterprise communication tools allow team members to quickly identify when context switching may be adversely impacting their ability to deliver business value. Issue trackers help highlight when certain individuals may unknowingly take on too much work across too many projects.

Ultimately, limiting the number of projects an individual team member works on is ideal. In those instances when splitting effort is required, however, leveraging DevOps tools and philosophies will help mitigate potential disasters, shift resources as needed, and continue delivering the business value necessary to your success.

Every two weeks, the SEI will publish a new blog post offering guidelines and practical advice for organizations seeking to adopt DevOps in practice. We welcome your feedback on this series, as well as suggestions for future content. Please leave feedback in the comments section below.

Additional Resources

Hasan Yasar and Aaron Cois will host a webinar, What DevOps is Not, at 1:30 p.m ET on March 11, 2015. To register for the webinar, please click here.

To listen to the podcast, DevOps--Transform Development and Operations for Fast, Secure Deployments, featuring Gene Kim and Julia Allen, please click here.