Performance Loss due to Project Switching
This post is a slightly edited version of an email I sent today in response to the question “Do you know any publications on performance loss due to switching from project to project?” I thought I gave a good answer, and I’ve wanted to write more about software engineering recently, so here it is.
It really depends on what is meant by “performance loss” and what the nature of the “switching” is.
The worst case scenario (while still remaining plausible) would be switching back and forth between 2 (or more!) projects in some sort of phased SDLC – that is, doing all of the analysis for project 1, then project 2, followed by all of the design for project 1, then 2, then coding & 2 and testing 1 & 2 and so on until you’ve shipped both projects. This may seem absurd to some people, and would definitely be a major process failure for an independent team, but in some cases this might be necessary; say, if specialist resources like designers and testers are a constraint, or if there are external dependencies. The obvious problem here is the greatly increased lead time for both of the projects. If the projects are of roughly the same size, the lead time has at the very least doubled (and that’s discounting any cost at all for context switching). This is a “Bad Thing” (there should be ample references in the lean literature about the benefit of decreased lead time), even if the scenario is not as blatantly bad as the one I just laid out.
For “performance loss”, it really depends on what’s being measured. If you’re thinking about lead time (which is directly related to throughput1, and thus revenue – in other words, you should always be thinking about lead time), switching (or expediting, a different manifestation of switching) will negatively affect performance. Tom Demarco argues in Slack that the real penalties for task / project switching are often hidden because of how people measure efficiency (number of hours worked / busy people as opposed to value delivered to customers, i.e. throughput).
As for actual loss due to context switching, which was possibly the original intent of the question, I think this may have been partially covered by Brooks in The Mythical Man Month, and according to a blog post by Jeff Atwood of Coding Horror this topic is discussed in Gerald Weinberg’s Quality Software Managemnt: Systems Thinking. I haven’t read this book, but the title is evocative of Peter Senge’s The Fifth Discipline: The Art and Practice of Learning Organization (which helped pioneer systems thinking). I haven’t had a chance to read that either (it’s on my to-do list!), but it’s pretty well regarded from what I can tell.
So, does anyone out there have some other references to exactly how switching from project to project can cause trouble? I’m looking for papers, books, studies and the like, not just restating of lean or agile principles, so you can’t just say “context switching is bad because is slows people down” – show me the study!
1Agile Management for Software Engineering, David J. Anderson [2003]
