Context Switching
Context switching is considered harmful
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. A human brain is not a CPU. For developers(for humans in general) a Context Switch can be extraordinary hard (and expensive).
Unfortunately, in a a software development environment there are external events that do their best to prevent the developer from maintaining this high concentration level. Changing from one task to another due to a more urgent problem, a client request or an important bug seems to be unavoidable. If you are a programmer working on some code and you are forced to change to something else, how would you proceed?
Researches have found that switching context requires a high level of concentration. It may cost up to 15 minutes until the same level of productivity and concentration compared to before the switching context can be achieved.
I remember a Peopleware's chapter talking about the huge amount of time wasted changing tasks. There are a lot of references about this topic.
For example: Joel Spolsky: "Human task switches considered harmful" or Jeff Atwood:"The multi tasking myth" .
Is there any way to minimize the impact of the context switch?
We are going to focus on how the version control can help handling context switching. Task switching causes you to have to “relearn” where you were before you can begin to be productive again. You suspend the current task and move onto something else. There is waste: you will probably end up copying the files to somewhere else, then preparing your working area for next task.There are two posibilities:
- Branch per task pattern
- Shelving, your changes and applying them later
The branch per task pattern
Why does not everyone use this pattern? There is no manual copying, no extra risk, no extra time.
Most of the version control systems out there have big problems dealing with branches. If make a branch is a painful task you will never do it.
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?
No branch per task pattern
The branch per task pattern is really helpful on task switching: commiting to the branch associated to the current task, then you just move to a new one.
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 days. Always having your own branch!
You protect your changes: 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.
Branch per task pattern
Shelve
The purpose of shelving is to save your pending changes when you are not ready to or can not check in a set of pending changes.
Shelving (or stashing) is a group of source file revisions, check-in notes and comments... In a familiar language: shelve the changes in a dirty working directory away
Context switching or interruptions, are one of the scenarios you can use shelve
- Interrupt: When you have pending changes that are not ready for check in but you need to work on a different task, you can shelve your pending changes to set them aside.
- Share: When you need to share changes with another team member, you can shelve your pending changes and ask your team member to unshelve them.
- Review: When you have to code-review, you can shelve your changes and inform the code reviewer of the shelves.
- Handoff: When you have work in progress that is to be completed by another team member, you can shelve your changes to make a handoff easier
Context Switching can really damage your bottom line by taking time away from actual progress on the tasks at hand. Use the branch-per-task working pattern and shelving to your advantage and your company's advantage. don't save changes to your own workstation anymore when you need to switch among different tasks. Let your version control system, like Plastic SCM, work for you, not against you.
Enjoy!
0 comentarios: