Multitasking Is Evil

[article]
Summary:
Multitasking is often seen as a desirable skill—you can buy books or pay to attend courses that will teach you how to do it—but it is a surprisingly debilitating idea.

Let me give you an example of one of the costs of multitaskingthe "switching cost." You've probably heard about it before, but this simple little exercise will help make it real. Go grab a friend who has a second hand on his watch and ask him to time you. Trust me, it's better to do this than just read it. It only takes a couple of minutes to complete.

Take a blank piece of paper or a whiteboard and draw three columns.

You are going to execute three projects, first using multitasking, then not. Your friend will time you for each.

The three projects are as follows:

Project 1: Write the letters A to J in the first column.

Project 2: Write the numbers 1 to 10 in the middle column.

Project 3: Write the Roman Numerals I to X in the third column.

The end result is three columns filled like this:

A | 1 | I

B | 2 | II

Etc.

Start with the multitasking scenario, which involves completing one row at a time. You need to complete the three columns, working row-by-row across the page, starting with A then 1 then I in the first row, working down the page until all three projects are complete.

Note your time.

Now start the non-multitasking scenario, which is where you start one project, complete it, then start the next project. In other words, you should start with column 1 and write down the page A to J, then move to the second column and write 1 to 10, then move to the next column writing I to X. Don't forget to time yourself.

Unless you are some freak of nature then you should see that you were faster when you didn't multitaskeven though you did that scenario second and would presumably have had some benefit from having completed the exercise once. Go on, confess: You didn't even need to look at the timings did you? Multitasking just felt slower. Did you make any mistakes when you multitasked? I did. But perhaps I'm not the best example hereI have to turn the radio down when I go through traffic lights.

Yes, I know, this example is contrived. But isn't real-life multitasking worse than this? Have you ever been in the situation where you've switched back to a task you were working on a few days or weeks ago, looked at it, and asked yourself, "What on earth was this about?" Our wee human brains aren't great at remembering huge amounts of detail. Can you remember what you had for dinner last night? How about the night before?

One of the key reasons why the agile approaches work is that they allow people and teams to "single task." That is, agile forces us to focus on doing just one smallish thing at a time. Iterations limit the amount of features a team can start, and most teams quickly discover that it is far easier to have each person working on one task at a time. Well-run maintenance teams tend to work on just a few small tasks at one time. Working in small batches is the key innovation of lean manufacturing and lean and kanban software teams. It's a lot easier to get one smallish thing right at a time than it is to get one large thing right or many small things right.

Run through the exercise one more time, and have your friend time just how long it takes to complete each project (column) in the two scenarios. Now imagine that, instead of it taking a few seconds per digit, it takes you a month per digit, and imagine that you get paid at the end of each project. Once you've done this exercise, take your numbers to your accountant and ask him which business is going to be the most profitable, have the happiest customers, and last the longestthe one whose projects finish quickly or the one where team members multitask and each project takes roughly three times longer to complete. That kinda makes the productivity loss from task switching seem small.

 

About the author

Clarke Ching's picture Clarke Ching

An independent consultant and regular columnist on StickyMinds.com, Clarke Ching is a passionate advocate of agile software development and a chairman of the AgileScotland special interest group. He is the author of the book Rolling Rocks Downhill, in which he demonstrates how to use lean, quality, and agile techniques to make your projects more productive and predictable. Read more about Clarke's work at www.clarkeching.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Aug 25
Aug 26
Sep 22
Oct 12