What's the most efficient way for a developer to switch between tasks?

Question

I'm looking for a workflow-type description of the series of steps you perform to switch from one software development task to another. If a step involves a tool, please specify which tool and how it's used. The goal of the workflow is to have the smoothest possible transition from task #1 to task #2 and back to task #1.

Consider this scenario...

• You're implementing a new user story and, while you've made progress so far today, it's not quite done and you haven't implemented your tests yet.
• Your lead comes to you with a high priority bug that's blocking your test team. You need to stop what you're doing and get the bug fixed. The bug is in a build from three days ago, which is the most recent build the test team has picked up.

You can fix the bug in a new version of the sources, but it has to be a stable version and can't include the incomplete feature you're currently working on.

Answer 1

Task switching is a thing of the brain. I don't think there is a tool to do that for you. If there is, I am also interested.

Each person has its own way of preparing, some don't prepare at all and are in another thing like a snap, some take more time etc. It depends on the man/woman.

Sure, you can try to create some mental milestones (taking a note, place a reminder etc) to return to it when getting back to the task, but this again depends on other factors (how long was the task switch, how quiet the office, familiarity with the task, moon phases etc).

The most efficient way for a developer to switch between tasks I think is subjective. Meanwhile, have you read the Human Task Switches Considered Harmful from Joel Spolsky?

Answer 2

Alt + Tab is how we do it.

Answer 3

Considering your scenario,
you could check out the stable version of sources in another working copy, correct the bug, commit.
When you come back to your incomplete work, do an update and continue to work.

Answer 4

When you're working on something you usually have a few ideas, few things you're planning to do, some stuff that is not clear and has to be solved later. It tends to get lost when you switch to other task.

I found it useful to write them down somewhere - take a brain snapshot. Later it's easier to restore it and get back faster to your original task.

Answer 5

I would say the steps you need to take in the scenario you describe are 100% dependent on the development environment and tools you have set up.

Using Perforce for source code version control, we have set up a branching system where the releases are separate from development work and all development branches stem from a single "acceptance" branch. Each branch is used for a single issue, or for a set of very closely related issues. No other issues can be worked on in a branch until the changes have been integrated up to the acceptance branch.

Yes, it does mean we have a lot of branches. Yes, we do a lot of syncing (acceptance down to a work branch) and integrating (work branch up to acceptance). But its worth is incalculable when it comes to easily switching from one task to another, going back to a test-built, spotting two issues biting each other, etc.

After development has done its thing (including their own tests), an issue is tested by the QA team. First in isolation in its own branch. After that is is integrated into the acceptance branch and a regression test is done to find any problems with independent issues biting each other. When all issues for a release have thus been integrated into acceptance, a full regression and new functionality test is executed by the QA team.

So, the acceptance branch is always the "latest" state of development for the app.

In this set up the scenario you describe would play out as:

• Leave my current task as it is, possibly check in any outstanding changes so as not to lose them when my computer crashes. If that means breaking a daily build of that branch, I wouldn't check in, unless it is easy to fix the compile errors. (Please note that we have many apps in our application suite and while my changes may compile in the app I am working on, they may still break the compilation of other apps in our suite) Our rule is: each submit may break functionality, but must not break the build process.

• Find an "empty" branch - a branch that is not currently being used for any development work, or, if all branches are taken, create a new one.

• Force sync the acceptance branch and the selected work branch so my machine is guaranteed to have the latest state for both branches.

• Synchronize (forced if necessary) the latest state of the acceptance branch to the work branch, so the selected work branch is the same as the acceptance branch.

• Open up that branch's application suite in the IDE, debug and solve. Submit to the work branch.

• Tell QA to have a look at it in the work branch. If they are satisfied with it, integrate the changes up to acceptance so they can continue their test.

• Switch the IDE back to work on the application suite in the branch I was working on before.

• Rinse and repeat.

Answer 6

I make a note of every file I'm working on inside of a Task/Todo item with a reminder in approx. the amount of time I will be away from it. Then I save and close each of those files to prevent them from distracting me/eliminate the clutter/create room for the new task on my desktop. I have the memory of a flea, so I need all the help I can get.