Joel Spolsky writes about context switching during development cycle. While he agrees that for developers switching costs much, he reminds that costs of denial to switch the context should also be considered.
I can say I fully agree with Joel. Sure, if there is a possibility to avoid often changes of tasks and priorities, you should go for that. Unfortunately, quite often it’s just not possible. It mainly depends on relation between a vendor and a customer. When the vendor is much bigger than the customer it’s easier to refuse to switch the context to bug-fixing. I don’t say if it’s wrong or right; it’s just easier. However, if the vendor is a small company delivering their solutions to one, much bigger, customer refusing to switch the context is not an option.
It’s always painful for me when I come to one of our developers telling him to leave whatever he’s actually doing and take care of support issue or another prior task. I know we’re wasting time then, but still I’m aware of cost of refusing to switch the context. I can count several most important customers for my company this year, including one which always orders some functional changes on day before yesterday. Without those few customers it would be hard to imagine my company still living by now. Can we reject them if they need our help? Can we reject because we don’t want our developers to switch context? Can we?
Sometimes I hear those who say that you should never do context switching when it comes to development work. I’d love to see them in a couple of situation I experienced. Those bad weeks, when everything goes wrong, one emergency situation appears just after another and you’re facing the risk of loosing contracts (and of course money) several times per day. I think it would be hm… quite an instructive view.