These days, computers made multitasking a doodle. In the same minute you can read this blog post, chat with friend on IM, check your email, Facebook or Twitter account, perhaps even do some work. We can switch our attention quickly from one task to another. But … is it good for our brain? Is it good for the work we are doing? Are we really more productive?
It’s been few weeks since I started to talk to people about context switching and multitasking. Most of them recognize it as an issue. Many agree that it is counter-productive. I decided to take closer look at the problem and do a little research. Here are the results.
Human brain
According to many Neurologists and Psychologists our brain was not designed for multitasking. In 1999, Jordan Grafman used MRI to scan people brain. He discovered that frontal cortex of brain of people engaged in multitasking was more active than any other. This part of the brain is the least known to science, it is said that this is “what makes us human”.
Psychologist René Marois discovered that there is a bottleneck in the brain, when it’s being stimulated to perform more than one task. David Mayer thinks, that rather than a bottleneck, brain has a process that helps to select and prioritise tasks and obey any instructions that are not on that list.
Russel Poldrack, a psychology professor found that “multitasking affects the way you learn”. He discovered that people who multitask while learning, use the part of the brain responsible for learning new skills (striatum). Rather, they should be using part of the brain responsible for storing and recalling information (hippocampus).
There is a dozens more of scientists that have done research in brain and psychology area that will confirm the fact, that we work better if we focus on a single item.
I like the words of American novelist Walter Kirn who summarises multitasking phenomena:
This is the great irony of multitasking–that its overall goal, getting more done in less time, turns out to be chimerical. In reality, multitasking slows our thinking. It forces us to chop competing tasks into pieces, set them in different piles, then hunt for the pile we are interested in, pick up its pieces, review the rules for putting the pieces back together, and then attempt to do so, often quite awkwardly.
Multitasking or context switching
It is easiest for me to talk about multitasking or the process of switching tasks (context) when talking about software development. During our development process quite often we are getting in the state which is defined by Mihály Csíkszentmihályi as the Flow . If we are getting interrupted or interrupting others it’s the Flow that suffer.
Receiving end of the stick
Think of the number of times that email, phone, IM chat, news ticker or anything else that interrupted your work. Very often we drop whatever we are doing and we answer an email. We are voluntarily destroying our context, switching to another one, just to get it back on track minutes later. This comes for a cost. It cost time and your focus. It is a typical distracter that actually we have control of.
We can also get interrupted by other people. Project manager, team leader etc. comes to us asking to stop working on whatever we are doing and do something else instead. Something small and quick, that is only going to take you 5 minutes. So we do that, and then we consume our mental energy on getting the entire context of interrupted task back on track.
As a developer I always work in the teams. My fellow developers always have some questions, problems that they might need a help with. I can’t tell them to buzz-off. I will be helpful and pay the cost of interruption later 🙂
The trouble maker
When we are in a despair and need answers we are not worrying about anyone else. The goal is to ask or tell to achieve whatever we are after. We are not taking into consideration that we might be disturbing someone else Flow.
It is the same when we aren’t using contact in person but electronic medium, like email, telephone or IM chat.
Too many things at the time
Almost 10 years ago, Joel Spolsky wrote on his blog:
As it turns out, if you give somebody two things to work on, you should be grateful if they "starve" one task and only work on one, because they’re going to get more stuff done and finish the average task sooner. In fact, the real lesson from all this is that you should never let people work on more than one thing at once. Make sure they know what it is. Good managers see their responsibility as removing obstacles so that people can focus on one thing and really get it done.
Getting tasks under control
When I started my short research on multitasking it became more and more obvious to me how Agile, Lean and XP methodologies are actually trying to bring the software development process to the state where individuals are focused on single task, complete it in full and move on to the next one. With no interruptions comes better quality as well. I would like to mention and shortly describe some of the techniques that could help team members to achieve the Flow and Focus and produce results.
Pair programming
You might think that having other person next to you means a constant interruptions, and impossibility finishing anything. Nothing more wrong. The positives that are coming from pair programming in the context of help with multitasking issue:
- having another person next to you and focusing on a work, limits you to NOT respond to email, chat invitations and cutting short phone conversations or generally do anything else not related to work
- engaged in a work you need to keep constant focus, follow your colleague and check (improve) the quality of result
- when you think you stuck on something, you have a mate next to you that can give you a helping hand (that limits the interruptions to others as well). Also with switching and rotating pairs you have constantly a fresh source of knowledge on the project areas you have never worked on
- it might be harder for someone to come over to you and ask about anything or ask to switch task to do something, as it is more obvious that he/she will be interrupting
There is more positives coming from pair programming but I will not write about it as it is a story for separate article.
Pomodoro technique
I was writing about the Pomodoro Technique in one of my previous posts “How can Pomodore help you shave a Yak?” Technique used will help with:
- keeping focus on a task for period of time
- adding short breaks to refresh the brain and take a step back to look at the task from a perspective
- when interrupted by other person or own thoughts, wri
ting the interruptions on a piece of paper makes you assure that the issues won’t be forgotten and ease your thoughts of it. This in turn helps you concentrate back on a task
- if you make people aware that, while you are in pomodoro you would rather be uninterrupted, you will be more effective
For more info on Pomodoro, you can look at my previous post or visit Google 🙂
Kanban
It could potentially take few more posts to describe Kanban. As simple concept as it is, it actually creates a wide range of improvements to development process. It is a great tool to be introduced by Project Managers for use by the entire team. Few upsides:
- working on a single item makes you focusing on a single task. The single story/task/functionality flow
- creating only quality results means that the actual task is not finished until QAs and BAs are happy with the result. This means that testing needs to come early into the process, even better – during the process (read this article by Christian Blunden, it will show you how)
- testing brought earlier, means also that you can help testers creating automated tests and keep in the same context until it is finished
Finally
It is in the basis of Agile techniques that work should be divided into small deliverable chunks (stories) that can be picked up and work on. If the chunks are small and team is disciplined, everyone will work uninterrupted until quality result is delivered. Project managers can employ techniques that help team members focusing on a single task and deliver it in full. I’m sure those techniques can save us many frustrating moments 🙂
This article is only a short introduction and brief summary of my little research project. I’m also preparing the talk and presentation with much wider explanation of the concepts and techniques mentioned in here.
Greg
Some of the sources if you would like to research more:
Today was the first day of QCon 2011 in London that I attended. I thought about sharing what I remembered while it is still fresh in my head (and the head is buzzing with ideas).
Recently I started to read a book, the one that 
Greg Gigon's wEbLOG 