I picked up an article doing the rounds by Joel Spolsky on context switching in Agile development and find myself a bit confused by the way he pitches his conclusion, even though I agree with most of what he says.

Context switching is something programmers first learn about in University purely in terms of what happens when a CPU or operating system has to stop doing what it’s doing, and do something else for a bit. It happens thousands of times a second on a modern computer, and is happening on your machine right now if you have more than one process running. Getting processors to the point where they can do that effortlessly took decades.

The next thing programmers learn about context switching is that they are expected to behave just as well as a modern CPU at context switching when they are expected to juggle dozens of projects at once. Interestingly, the people who expect this, don’t understand what is required to handle a context switch for a programmer and see their new piece of meat as being a bit like a messy version of OS/2 Warp, but perhaps not quite as fast.

In the past I’ve written about what I call alone time - the point where a programmer will try and get into “The Zone” and become as productive as they possibly can. I think those two articles hint at why a context switch is so hard. It disrupts a work-flow that is hard to obtain. You can’t easily drift in and out of a context when you’re being productive.

Joel agrees with all of this, but says “hey, you know, sales are important, sometimes it’s worth the context switch, that’s what Agile development is all about”. The problem is, he’s talking complete rubbish.

Agile is about how to manage the development of a single project: one project on the radar, iterations, feedback, customer contact, the code is the specification. You get the idea.

You don’t use Agile to handle multiple projects. For that you need something completely different. The context switch is something that agile isn’t designed to handle, because it assumes that as a development manager you wouldn’t be so utterly irresponsible, moronic and boneheaded to attempt to try and get a developer handling several projects at once. It’s a limitation of Agile, which is why you need something else in most programming teams to handle it.

Right now I have seven projects on the board, two of them able to wait a while, three of them less than 24 hours from being signed off, and the remaining two due to last through for another week or two - I then intend to take a month off Christmas and sleep. Right now, I need to context switch even though I know it’s not ideal. The way I do that has nothing to do with Agile development, and everything to do with how I plan my time.

In the example Joel points to, the answer is not “this is Agile, deal with it, be Agile”, the answer is to say to the developer “look, do you want some overtime to look at this?” or to find a developer who isn’t busy to look at it instead. It’s about time management and handling more than one project, not about forcing a method designed for one project into something it isn’t.

Juggling multiple projects, handling resource allocation and managing the board in a busy programming team is hard work. It isn’t something Agile can fix, so don’t blame it when it doesn’t, and let programmers stay in context as long as possible if you want them to be productive.

I’m just about coping by handling this my own way, but in the New Year I’m hoping to hire a developer to help me out and let me stay in context for longer.