Was Email a Mistake?
Was E-mail a Mistake?
A striking computer-science discovery from this period is the difficulty of the so-called consensus problem. Imagine that each machine in a distributed system starts an operation, such as entering a transaction into a database, with an initial preference to either proceed or abort. The goal is for these machines to reach a consensus—either all agreeing to proceed or all agreeing to abort. The simplest solution is for each machine to gather the preferences of its peers and then apply some fixed rule—for example, counting the votes to determine a winner—to decide which preference to adopt. If all the machines gather the same set of votes, they will all adopt the same decision.The problem is that some of the computers might crash. If that happens, the rest of the group will end up waiting forever to hear from peers that are no longer operating. In a synchronous system, this issue is easily sidestepped: if you don’t hear from a machine fast enough, you can assume that it has crashed and ignore it going forward. In asynchronous systems, these failures are more problematic. It’s difficult to differentiate between a computer that’s crashed and one that’s delayed. At first, to the engineers who studied this problem, it seemed obvious that, instead of waiting to learn the preference of every machine, one could just wait to hear from most of them. And yet, to the surprise of many people in the field, in a 1985 paper, three computer scientists—Michael Fischer, Nancy Lynch (my doctoral adviser), and Michael Paterson—proved, through a virtuosic display of mathematical logic, that, in an asynchronous system, no distributed algorithm could guarantee that a consensus would be reached, even if only a single computer crashed.A major implication of research into distributed systems is that, without synchrony, such systems are just too hard for the average programmer to tame. It turns out that asynchrony makes coördination so complicated that it’s almost always worth paying the price required to introduce at least some synchronization. In fact, the fight against asynchrony has played a crucial role in the rise of the Internet age, enabling, among other innovations, huge data centers run by such companies as Amazon, Facebook, and Google, and fault-tolerant distributed databases that reliably process millions of credit-card transactions each day. In 2013, Leslie Lamport, a major figure in the field of distributed systems, was awarded the A. M. Turing Award—the highest distinction in computer science—for his work on algorithms that help synchronize distributed systems. It’s an irony in the history of technology that the development of synchronous distributed computer systems has been used to create a communication style in which we are always out of synch.Anyone who works in a standard office environment has firsthand experience with the problems that followed the enthusiastic embrace of asynchronous communication. As the distributed-system theorists discovered, shifting away from synchronous interaction makes coördination more complex. The dream of replacing the quick phone call with an even quicker e-mail message didn’t come to fruition; instead, what once could have been resolved in a few minutes on the phone now takes a dozen back-and-forth messages to sort out. With larger groups of people, this increased complexity becomes even more notable. Is an unresponsive colleague just delayed, or is she completely checked out? When has consensus been reached in a group e-mail exchange? Are you, the e-mail recipient, required to respond, or can you stay silent without holding up the decision-making process? Was your point properly understood, or do you now need to  clarify with a follow-up message? Office workers pondering these puzzles—the real-life analogues of the theory of distributed systems—now dedicate an increasing amount of time to managing a growing number of never-ending interactions.Last year, the software company RescueTime gathered and aggregated anonymized computer-usage logs from tens of thousands of people. When its data scientists crunched the numbers, they found that, on average, users were checking e-mail or instant-messenger services like Slack once every six minutes. Not long before, a team led by Gloria Mark, the U.C. Irvine professor, had installed similar logging software on the computers of employees at a large corporation; the study found that the employees checked their in-boxes an average of seventy-seven times a day. Although we shifted toward asynchronous communication so that we could stop wasting time playing phone tag or arranging meetings, communicating in the workplace had become more onerous than it used to be. Work has become something we do in the small slivers of time that remain amid our Sisyphean skirmishes with our in-boxes.There’s nothing intrinsically bad about e-mail as a tool. In situations where asynchronous communication is clearly preferable—broadcasting an announcement, say, or delivering a document—e-mails are superior to messengered printouts. The difficulties start when we try to undertake collaborative projects—planning events, developing strategies—asynchronously. In those cases, communication becomes drawn out, even interminable. Both workplace experience and the theory of distributed systems show that, for non-trivial coördination, synchrony usually works better. This doesn’t mean that we should turn back the clock, re-creating the mid-century workplace, with its endlessly ringing phones. The right lesson to draw from distributed-system theory is that useful synchrony often requires structure. For computer scientists, this structure takes the form of smart distributed algorithms. For managers, it takes the form of smarter business processes.Isolated examples of well-planned, structured synchrony are starting to emerge in the business world. Many of these experiments come from the tech sector (where, perhaps not coincidentally, the ideas behind distributed-system theory are familiar). Recently, the founder and C.E.O. of a publicly traded technology company told me that he spends at most two or three hours a week sending and receiving e-mails; he has replaced most of his asynchronous messaging with a “regular rhythm” of meetings, which allows him to efficiently address issues in real time. “If you keep needing to send me urgent messages, then my assumption is that there’s something broken about the way you’re doing business,” he said.Similarly, the software-development firm Basecamp now allows employees to set professor-style office hours: if you need to talk to an expert on a given subject, you can sign up for her office hours instead of shooting her an e-mail. “You get that person’s full, undivided attention,” Jason Fried, the company’s co-founder and C.E.O., said, on the podcast Curious Minds. “It’s such a calmer way of doing this.” If something is urgent and the expert’s office hours aren’t for another few days, then, Fried explained, “that’s just how it goes.”At many technology companies, a popular alternative to hyperactive asynchronous messaging is a collaboration framework called Scrum, popular among software developers. Teams of programmers using Scrum divide their efforts into “sprints,” each focussed on introducing a related set of features to a piece of software. During these sprints, which last from one to four weeks, the team meets once a day. Everyone gets a chance to speak. Team members describe what they accomplished yesterday and what they’re going to work on today; if they think they’ll need help, they let the right people know. In classic Scrum, colored notes pinned to a board are arranged to publicly reflect these commitments, so that there’s no ambiguity about the plan. These meetings are often held standing up, so that no one feels tempted to bloviate, and they typically last for around fifteen minutes. The idea that a quarter of an hour of structured synchrony is enough time to enable a full day of work might sound preposterous, but, for more than twelve million software developers, it seems to be working. Many people are surprised when they first learn about the effectiveness of Scrum. This suggests that many of us are underestimating the value of synchrony: when organized properly, it’s more powerful than we realize.We can acknowledge, with the benefit of hindsight, the reasonableness of the hypothesis that asynchrony in the office would increase productivity. We can also admit that this hypothesis has been largely refuted by experience. To use the terminology of computer science, it turned out that the distributed systems that resulted when we shifted toward asynchronous communication were soon overwhelmed by the increasing complexity induced by asynchrony. We must, therefore, develop better systems—ones that will almost certainly involve less ad-hoc messaging and more real-time coördination.From this perspective, our moment in workplace history looks rather different. The era that will mystify our grandkids is ours—a period when, caught up in the promise of asynchronicity, we frantically checked our in-boxes every few minutes, exhausted by the deluge of complex and ambiguous messages, while applauding ourselves for eliminating the need to speak face to face.