Even simple multi-tasking can make a project 30% late
Twitter
Facebook
Delicious
Digg
Stumble
Reddit
Until I saw this link on Guy Kawasaki’s blog, I thought the ability to multi-task was something to brag about. Now I wonder …
Guy read the article on a blog called LifeRemix. Here are some excerpts from the post:
In a project setting, it’s easy to get distracted and try and complete multiple tasks instead of just working on one. This article argues that multi-tasking is not only a bad mindset to have, but it can actually make projects up to 30% late, with only one instance of multi-tasking going on.
When multi-tasking happens, your brain has to mentally go back to the beginning and let your mind catch up to the beginning of the last task you did.
Multi-tasking is the act of stopping a task before it is completed and shifting to something else; in software development the term “thrashing†is often used to describe this practice. When a task is stopped and started there is the immediate effect of a loss of efficiency. Each time a person has to re-start a task, time is required to become re-familiarized with the work and get re-set in where he was in the process. It is very much like the physical set-ups done on a machine in production. Each time you tear down a machine to do another task, you have to set it up to run the part again.
This was earlier written about in detail on another blog – The theory of constraints. I thought it was an interesting perspective. Not sure I agree with it though. I have multi-tasked for years and I find that I get a lot more done than when I just focus on one task. Maybe each of us is different in how we handle tasks. Perhaps it also depends on the kind of work one does and whether the tasks are being handled by a single individual or it is a team effort. Nonetheless this theory made sense and I thought I’d share it with everyone.
11:52 am
Similar thoughts are shared by joel spolsky on his blog. Here are some extracts
“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.”
you can read the full article here
http://www.joelonsoftware.com/articles/fog0000000022.html
1:17 pm
Ammar, I totally concur with Joel that multi-tasking for programmers is a complete no-no. I have noticed that when they are programming full-throttle, even a phone call can put a halt to the process. And it irritates the hell out of them. The question is, is this equally applicable to other members of the team – i.e. interface designers, project managers, operations managers, etc.?
6:23 pm
I dont think Managers shoudl be affected by thread switching — in fact all good managers should be ABLE to switch threads and gain the new context in the shortest amount of time — how else will they manage a myriad of issues from their team and environment?
Interface design — however — isnt just a creative art. It also requires keeping in mind a large number of target workflows, user demographics, use-cases, other related interfaces and more. Ofcourse that depends on how well defined and consistent the “global interface” rules are (e.g. all File Open dialogs should look the same etc).
From my side I love task switching — its a sure-shot way of keeping at a 100% of personal productivity. That’s the only way I have been managing Green & White, consulting, running a company, designing products, planning new initiatives, not to mention the administrative / operational stuff.
However I absolutely agree with programming — there is just no way to multi-task and program, and any time I have to look at anything I’m faced with a 2-3 day rampup time (to put everything in short-term RAM so to speak) and then a 100% mental capacity and bandwidth spent on the code itself.
Personally, I consider this a weakness of IDE user experiences, not necessarily a consequence of the work.
6:34 pm
Some additional food for thought tho, and this comes from traditional supply-chain management:
Task switching becomes painful when the load-time and tear-down time are too much and the actual processing does not maintain state.
Consider an assembly line where you can either make Widget X or Widget Y but not both. The production-time (goign from one point to the other in the assembly line) is 30 mins, but rampup and teardown time each is 2 hours. Its stateless because you cant just “pause” the open parts when you want to make widget B — you just have to take everything off the table and start again.
The human mind in some ways is similar — there is pretty much ONE main assembly line. Some of the smartest people are able to create two but then that’s not everyone.
The rampup time is the time used to gain context. The teardown time is the time taken to write everything down somewhere so you dont forget later on.
Phonecalls disrupt this assembly line — its like one of the machine breaking causing the entire line to stop, or worse.
So how do you solve this problem?
1- You use some way of scheduling the items loaded in the assembly line by order of priority, opportunity cost, and total production expectation of the day.
2- You find a way to minimize rampup time — usually (in SCM) by preparing “ready to go” kits of the parts, along with “fixed rules” of how those parts will be processed.
3- You add a way of maintaining state — as an example, what if you could simply move the actual table with all the parts just like they are, put in a blank table, make Widget B, then move tableA back in?
In the above three things, “fixed rules” are the processes established in the firm, “parts” are pieces of information or context needed to complete your task.
I think the above three duties is what software productivity tools should be doing — unfortunately most only focus on #1, and not context maintenance.