In Quality Software Management: Systems Thinking, Gerald Weinberg proposed a rule of thumb to calculate the waste caused by project switching:
The problem with task switching is that many times it’s unavoidable. When our project manager left for a new job, I went from dedicated junior developer who only focused on the code to project manager / developer / tech support / tester / etc.
While I agree that multitasking kills your productivity when writing heavy duty code, it has also forced me to become a much better programmer. I believe my code is better because if it.
Instead of just working off hear say from a project manager, I’m actually dealing with the clients and understanding the fundmental problem they are having with the system. I’m able to easily communicate possible solutions and determine the best course of action for the problem at hand. When you aren’t in charge of all these things, then it seems like a lot slips through the cracks during the communication process.
@Ryan your example deals with different aspects of the same project. Jeff warning is about switching rapidly between very different tasks.
@J.Allen, I think you hit an important point. But the warn is about not abusing.
There’s a difference between planned context switches, as discussed in the comments, and unplanned context switches due to interruptions like email, phone, etc.
If a context switch is planned, you plan in time to save state (as it were). If your boss comes in with yet another wild hair, and says “do this now”, there’s no chance to save state, and the context is lost – to be recovered later.
This goes well with the concept of getting in the zone, which can take quite a bit of time by itself.
It’s a real problem to me. Even working on just one project, I always get the temptation to check my emails or read some news, under the pretext that I need to relax (which is true but needs not happen every 10 minutes). The result is a mediocre productivity 
I sometimes think that companies should restrict internet use because, working with a computer, it is really difficult to not wander away from your main task. Even reading pages related to your work can easily distract you, because there are all these interested [technical] topics just one click away…
I actually find a reboot to be a good thing. For instance right now: I give myself 15 minutes to waste time on your blog (and Phil’s and Scott’s) to clear my brain. “Mind like water” and all if that’s to be believed.
Joel’s point is valid, but I think one thing these guys might be overlooking is that if you have your process down, you don’t need to keep all your bunnies in a shoebox.
Also - as many of the comments point out, you can’t escape this. Push-me Pull-you is a fact of life. If you implode with more than one project it might be time to move the booty to a cubicle :).
I’ve also seen a number of articles lately that point out that kids ARE better at multitasking than adults. They’ve grown up with cell phones, internet etc. Maybe it’s just that x + 7 = 11 isn’t all that hard compared to asynchronous device managers, but all studies also say that the brain just adapts faster when you’re younger. It’ll be interesting to see when the Y generation hits their 30s and 40s whether multitasking is considered harmful or something that senior citizens talk about. Sign me up for the old folks home, I can’t talk on my cell and remember to turn left on my way home.
Jeff,
I think I should point out that this issue is not that simple.
Men and Woman’s brains are different. Women can multitask better than men because we evolved that way.
Back when the human race was forming the male was the hunter and had a single task of finding prey, killing it and dragging it home. All serial tasks. While the women stayed close to home, cleaning, cooking, gardening while whiching over a pack of kids. Women had to do all of this at the same time while keeping in mind where each kid was in relation to incoming preditors like the mean saber tooth tiger. Women developed a multitasking brain.
Now this isn’t to say that men have completely different brains as women (or vice versa) but we all fit somewhere on a continuum. Some men can multitask because there brain had developed and evolved through the generations as a female brain.
My point is that there are people (men and women but more women than men) who can mulitask.
(Wish I had a spell check in the comments)
Responding to the “different female brain” point and the “children” point in one fell swoop, remember that from an IT standpoint the question is about “high-context” tasks. Press me and I can carry on two duplexed conversations simultaneously (although that taxes me to my limit and they’d better be completely unrelated).
But compared to programming, your average conversation is a low-context task. If you come in on a conversation between two of your friends, the amount of time it takes you to come up to speed and contribute something useful is often measured in seconds. For a programming task, I’m lucky to have my first file opened in that time, let alone have anything useful done.
With no intended slight towards the challenging task of being a mother, almost everything you need to know about the cleanliness state of the kitchen is contained in the kitchen itself. (Which is, if you think about it, the reason a dirty kitchen is a problem in the first place.)
I doubt a 15-year-old is that much better than me at carrying on 10 IM chats. I remember being 15, I remember exactly how hard homework was. I’m sure I could have done 10 IM chats and my homework too. The homework is slower, but who cares? You’ve got more than enough time. Programming is different, because it’ll take everything you’ve got and more; you really can’t be too good a programmer and what you spend on 10 IM chats isn’t being spent on being a programmer. Even if task switching was free, you’d still be impaired vs. fully concentrating. (You also tend to have the opposite time situation.)
The high-context nature of programming is critical to the point. People have been “multitasking” low-context tasks forever without a 90% penalty to 5 tasks. That’s probably why the high-context penalty is so shocking to people; we haven’t got an intuition for it because almost everything we do is low-context by comparision.
Probably the oddest thing is that our brains can handle these high-context activity at all; there really doesn’t seem to be a call for it in nature.
Sometimes we simply need to think about something in a relaxed way rather than sitting at our desk looking busy for the sake of it. A change really can be as good as a rest, if we are able to choose a sensible time for the change.
“Probably the oddest thing is that our brains can handle these high-context activity at all; there really doesn’t seem to be a call for it in nature.”
That, our philosophical and spiritual nature, and the lack of linking evolutionary fossil record tends to suggest an alternative species genesis than evolution.
Well, steveth45 is clearly clueless. Let’s not adopt multi-tasking as yet another “proof” of the influence of cod on our daily life and our existence. If cod or a facsimile thereof even exists, which I personally doubt, then they are a fickle cod and hopefully will get over-fished to extinction by whatever “powers” dominate cod’s surroundings.
That said, I think I agree with Jeremy Bowers in that people are able to multi-task (all people including us stupid, tunnel visioned, ego-driven, militaristic and generally evil hunter types not just the intelligent, caring and inherently good gatherer/child nurturer types). Last I checked, most of us (except steveth45) can walk and chew gum at the same time. Most of us can read a book and draw parallels to our life experience.
What is not being said here about mental context switching while programming is the complexity of the code. Joel Spolsky’s quote touches on this (but only at the negative side) when he says “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,”.
The complexity of the code you are working within is perhaps the single most important factor in whether you can/can’t context switch quickly. If the code is well architected, well designed with clean, cohesive components and classes, context switching is not very expensive. You move to a domain where the things in the domain accurately model the problem space; understand the problem and you understand the code. On the other hand, if the code is bailing wire, bobby pins and brute force algorithms, then the context switch can be huge.
One chunk of code we had on a project was so complex that, after some analysis, we determined that it took a developer about one full work week to ramp up to the point where they could fix a bug. Additionally, because of its complexity, if you left that task for a couple of weeks and came back to it, it once again took you 3-5 days to ramp up. This was code that was built with brute force logic, poorly cohesive data structures and with if statements to handle every bit of variable behaviour (as opposed to encapsulation with polymorphic or aggregated handling of behaviour).
This brings me back to Joel’s quote - if the codebase requires a programmer to keep “zillions of things in their head at once” then it (or more accurately, its creators) is at fault for the time a developer spends context switching.
The gut check here is, if it takes you or somebody else a long time to ramp up on your code, then odds are you’re not a good programmer. Odds are you are one of the ones we laugh at when we consider the recent finding that “95% of all software developers believe they are above average”. 45% of them MUST be wrong. To quote a line from Dire Straits “Industrial Disease” and a quote sure to please steveth45
"Two men say they’re Jesus, one of them must be wrong".
It is cheaper, if you’re a dumber-than-a-sack-of-hair manager (extra points for where that comes from) to treat programming like assembly line work. Managers, to repeat, most always come up through sales; even when the area is technical. Only sales folk really know anything, and often have an MBA. And so on.
Programmers aren’t even assembly line help, they’re farm workers. Why all the whining?
The Dire Straits quote is telling: Mr. Dudra is either old enough to actually know something, or a very precocious youngun.
Mr. Dudra is old enough to be able to carefully give the impression that he actually knows something, regardless of whether or not he does.
I also agree that treating developers like interchangeable assembly line workers is, for the most part, absurd. It goes to the whole mythical man month thing that given X units of work, if you throw N work units (a.k.a. developers) at it, you will be done in X/N time (although most development managers and RD directors seem to assume floor(X/N) - 10% for great management).
Unfortunately, it is a reality of the industry that people must switch projects from time to time. For this reason, it is imperative for managers to a) understand that there is a cost to this and factor it in - great management doesn’t offset this (even when it is real and not imagined) and b) that developers must understand this and pursue the most readable, most cohesive and least coupled code they can so that the cost of a context switch is as small as possible. Saying “our code is complex; you can’t switch me on and off of it like that” is paramount to saying “We are doing a bad job so it makes it very hard for us to go elsewhere and then come back to our substandard and difficult to understand work”.
Sorry, no time to proofread - the lamb chops are cookin’.
Oh my god “I just admitted to eating MEAT!” Once again I shall be a pariah …
Surely Tim code that is complex to understand and difficult to maintain could be assumed to be legacy code. As such you have to sit down and understand it to make a small change (small from the business point of view).
You don’t necessarily say hey this is complex to fix so we should rewrite it instead - most businesses don’t want to pay for something they already have, they just want this little extra thing.
Dealing with complex code is something every programmer will have to do, whether they are good or bad.
I’m not disagreeing with you Paul.
A point I often try to make, and perhaps am trying to make here, is that legacy code is complex and difficult to maintain because it is old code. As my former boss, Steve Adolph, once told me (and I paraphrase 'cause my mind ain’t what it used to be),
“Every time you open up a piece of code and make a change, you leave damage. It is like operating on a person; each time you open them up to fix a problem, you leave behind scar tissue”.
With enough changes to any codebase, it becomes old, fragile and brittle. Then it is painfully expensive to modify. True legacy code that has evolved over time cannot be prevented.
However, the point I am implying is that the vast majority of code is hacked out without design. Its design, if any, is at best some vague whiteboard scribblings and maybe a brief one or two page analysis of the sunny-day scenario where all goes well. Then, this “design” is encoded by people who all too often allow the debugger to do their thinking for them. I’m sure you’ve seen it and even done it (I know I have) - you write a for loop or similar construct and think “Gee, does that actually do want I want? I’ll go through it in debug”. Code built in this manner is code that NEVER had a chance to be young. It was born old, like those cloned sheep in England, because its birth was a long painful process of opening it up, hacking in a patch, and stitching it back together again. Before it is even released for the first time, it is a nightmarish twining of sphaghetti. It is that kind of “legacy” and/or “complex” code that I am suggesting should not occur.
But I can code and read Coding Horror posts still, right?
Obviously! Otherwise how would you possibly know how much time you just wasted?
One thing to consider, however, is experience. Although multitasking is not the ideal scenario, an individual who is required to frequently multitask may be much more adept at it than someone who is normally assigned to just one project and isn’t forced off track too often. Sure there is still a performance hit but it is amazing the changes ye ole gray matter can make when necessity dictates.