Why we’re betting against real-time team messaging
This is an example of why I flatly refused to install an IM client at a former employer who wanted IT staff connected and instantly available. (The issue was laid to rest in a conference call when a co-worker said "The nice thing about Dennis is that if he's at his desk, he answers the phone on the first ring.  If he's not at his desk, you won't get hin in IM, either!"  Bless him.  He <i>got</i> it.)<p>The sort of stuff I did was mostly not user facing, since I was admin for the nix boxes, and not usually supporting Windows on the desktop.  The things I did tended to require peace, quiet, and extended concentration to make sure I understood the problem and had created a working solution that wouldn't blow up in someone's face.<p>The underlying problem is that computers are good at multi-tasking, and humans <i>aren't</i>.  When a computer is handling multiple concurrent tasks, and an interrupt comes in, it must save its place in what it's doing at the moment, handle the interrupt, then go back to the saved place and continue where it left off.  It's stack processing, computers are designed to do it well, and are generally fast enough that the user thinks the computer is only doing the task she's working on.  The overhead isn't apparent.<p>Humans <i>aren't</i> good at stack processing.  I've seen papers from years back indicating the average developer can handle 5-7 parallel tracks at a time, and beyond that, things get lost.  Stuff getting lost because the developer was trying to keep track of too many things were highly fertile sources of bugs.<p>And humans aren't anywhere near as fast as computers.  Conceptually, you do the same thing as a computer - you are working on a task and get interrupted.  You must save your place in what you're doing, handle the interruption, and resume where you left off.  There is <i>significant</i> overhead there, and if you get interrupted enough, you spend most of your time stack processing instead of actually working on tasks.  You get the equivalent of old time mainframe "death by thrashing", where the mainframe was spending more time context switching than actually doing work.<p>Some of us are better at multi-tasking than others, but I think <i>all</i> of us over-estimate how good we actually are.  I've advised folks elsewhere to try an experiment - work on <i>one</i> task at a time, and <i>continue till it's completed</i>, instead of juggling multiple concurrent tasks. I'm willing to bet the amount of work you actually get <i>done</i> will jump.<p>What confuses me is why the shop in the article thought that sort of real time communication  was a good idea in the first place.<p>>Dennis