A recent Harvard Business Review post highlights the advantages of doing one task at a time without context switching. The post has received over 700 comments so far, many of which talk about the challenges in doing one thing at a time while building software and how techniques like Kanban and Scrum can help address them.
As Tony Schwartz points out in his post, context switching has a detrimental effect on productivity.
“In part, that's a simple consequence of splitting your attention, so that you're partially engaged in multiple activities but rarely fully engaged in any one. In part, it's because when you switch away from a primary task to do something else, you're increasing the time it takes to finish that task by an average of 25 per cent.”
Joel Spolsky provides a programmers perspective to the same issue.
“The trick here is that when you manage programmers, specifically, task switches take a really, really, really long time. That's because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming. A programmer coding at full throttle is keeping zillions of things in their head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code. If you send that programmer to Crete for a three-week vacation, they will forget it all. The human brain seems to move it out of short-term RAM and swaps it out onto a backup tape where it takes forever to retrieve.”
Greg Gigon talks about how Agile methods focus on breaking requirements into small deliverable pieces of work which enables us to sooner than later finish one piece and start working on the next one. Using a card wall to synchronize the work, like in Scrum and Kanban, allows people to signup for one task at a time and getting it done before moving on to the next one.
Pair Programming makes people less likely to check on emails and social networks while pairing on a task. As this recent TechCrunch article points out
“It’s just with two people working together the urge to check personalized services (including email) usually waits until a creative break. i.e. more time on task.”
Techniques such as Pomodoro and Personal Kanban can be very useful in managing one’s time and prioritizing and completing work.
Some Agile teams have resorted to asynchronous mediums of communication such as instant messaging; blogging and using an internal wiki to minimize disturbances within the team. Another interesting solution offered by Charles Miller at Atlassian is to have someone assigned as ‘The Disturbed’.
“Our solution was to designate a single developer to be “The Disturbed”; taking a two-week stint to act as a magnet for all the questions, requests and distractions that would otherwise be distributed across the whole team.”
However, both Joel Spolsky and Don Reinertsen warn against just focusing on the cons of context switching by offering certain contrasting benefits.
Don Reinertsen talks about cases where parallel secondary activities could improve the quality or efficiency of the primary activity
“For example, most engineering degree programs force students to switch context between different subjects. We could teach a year of pure math before we tackle physics, but students would have a much harder time seeing the connections between these two subjects. Similarly, as an author, I never write my books by completing single chapters in isolation. By periodically shifting between chapters I can achieve much better integration between them. Authors who work one chapter at a time often lapse into repetitiveness. By the time they are writing Chapter 10, Chapter 1 is a distant memory.”
Joel Spolsky provides another example where a critical production bug in a piece of software could take an urgent priority and demand a programmer to stop what he was doing to fix the bug that affected valuable customers.
Don Reinertsen further concludes that
“If you find yourself instinctively trying to reduce context shifting you should ask yourself two questions. First, have you done everything you can to lower the cost of switching context? Second, are you capturing any benefits by switching contexts? If the benefits of context switching exceed its cost, then don't try to eliminate it.”
What have your experiences been in switching context while building software? What practices have you adopted to minimize them?