Developer context switching

Context switching is considered harmful. No matter who is talking about it, it is clear that forcing people to change from one task to another is an extra overhead that we all face during development.
I remember a Peopleware's chapter talking about the huge amount of time wasted changing tasks. More recently (and that's basically why I'm writing about it) I read an entry on Joel's blog dealing with the same issue. But as Joel states: switching is not always possible to avoid.

So, ok, changing from one task to another due to a more urgent problem, a client request or a important failure seems to be unavoidable... and the impact is very high. Is there any way to minimize the impact of the context switch?

If you are a programmer working on some code and you are forced to change to something else, how would you proceed? Normally you would have some files you are working on, and most likely your changes are not yet done. So what would you do with your "in progress" work? You are probably using some sort of version control, but submitting unfinished changes to the server doesn't look like a very good idea. So, what to do? You will probably end up copying the files to somewhere else, then preparing your working area for the next task.

The figure shows the situation. Even having a source control system, the programmer ends up manually copying files. It doesn't look very good. Besides, all these changes are outside the version control for a certain period... who knows for how long?

What can happen to these changes in the meantime? What if switching back again takes longer than expected? What if something goes wrong with the developer's computer?

Most of version control systems out there force you to follow the depicted scenario. Ok, not all of them, and that's basically why I'm talking about it.

What about using the version control system to handle context switches? It can be done using the branch per task pattern. You create a branch each time you have to work on something, whatever it is, for an small change to a task that will last several weeks. So, having your own branch, you can protect your changes (I mean checking in to the version control system) as many times as you need to. Intermediate changes are saved, all developer's work is stored on the central repository (your team can even avoid making backups of the developer's workstations), so no more I guess the right code was at your computer.

And it is really helpful on task switching: you check everything in, commiting to the branch associated to the current task, then you just move to a new one. No manual copying, no extra risk, no extra time. You just use the tool.



So, if it is that easy... why is not everybody doing it? Limits! Most of the version control systems out there have big problems dealing with branches, that's why you can't even think of using branch per task, and context switching will be painful. And that's why we have designed Plastic SCM around the concept of easy branching. You can easily follow the proposed strategy with our tool... and you will see the difference... :-P

Enjoy!