Why we’re betting against real-time team messaging

oops,

I meant *

thanks

TLDR: why NNTP is better than IRC. 30 years later. New frontend, same problem.

I feel old.

> Accounts are completely separate from Facebook, no crossover at all.

This was the claim that was made when we tried out FB@W, but shortly after I created my work account (I don't have a personal account) my wife started getting friend suggestions for coworkers of mine she's never met. I never even used my @work account for looking at her FB account, wasn't friended to her, etc.

I think it was either a) harder to undo all the creepiness, or b) they didn't want to.

Usenet was not historically real-time because of several things:

1. There were a lot of servers.

2. The servers were not arranged in an optimal network.

3. The network was full of cross links, many of which made no topological sense.

4. Not every server carried all newsgroups.

5. There were a lot of users, who read a lot more than they write.

6. Binary messages (when carried) grew to huge sizes (for the time).

7. Network links were very slow by today's standards.

8. Disks were slow, small and expensive by today's standards.

9. Every ISP felt it had to provide free Usenet service, but few of them did it well.

With modern hardware, Usenet could be as close to realtime as you expect email to be -- dominated by people's attention and writing speed. And carried over TLS, of course.

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 got it.)

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.

The underlying problem is that computers are good at multi-tasking, and humans aren't. 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.

Humans aren't 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.

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 significant 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.

Some of us are better at multi-tasking than others, but I think all of us over-estimate how good we actually are. I've advised folks elsewhere to try an experiment - work on one task at a time, and continue till it's completed, instead of juggling multiple concurrent tasks. I'm willing to bet the amount of work you actually get done will jump.

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.

>Dennis