Technology Companies As Distributed Systems

I once saw an intelligent comment on Hacker News:

Asynchronous communications are best for development teams. Taking out an exclusive lock on every developer’s full attention for 15 minutes is extremely dumb.

If you’re a programmer, you already know why this is true. If not, consider this comic, which was retweeted and linked to so widely that it crashed the server it ran on.

Writing code is like making a mosaic. Mosaics are made of colorful tiles. Say you’ve picked out your next three rows of tiles, and stacked them in order, and mixed your adhesive, and you’re ready to start laying tiles. An interruption comes along and scatters those tiles.

Or consider how Paul Graham phrased the issue:

It’s not easy to get a program into your head. If you leave a project for a few months, it can take days to really understand it again when you return to it. Even when you’re actively working on a program it can take half an hour to load into your head when you start work each day.

His first two pieces of advice on this are “avoid distractions” and “work in long stretches.” And every programmer’s discovered these tactics. You can’t write code without them.

So consider: you’ve got a system. This system’s composed of multiple entities. Each one processes code and transforms it. Each one has a very long boot time. Each one must reboot if it’s interrupted. What is the best way to handle interprocess communication here?

Of course, the answer is asynchronous communication.

There’s a reason most successful open source projects, and many successful companies, have converged on remote development. Modern society is rebuilding everything to run on computers. We are trying every mode of software development; some are succeeding and some are failing. If a common theme emerges from that chaos, it’s wise to pay attention to it.

It’s not that being around people is inherently bad. Being around people is often good. It’s not that introverts outnumber extraverts in this particular field, although anecdotal evidence suggests that they probably do. And it’s not that offices are inherently toxic, although many offices are indeed physically harmful to your health. It’s that synchronous communication is simply a terrible fit for concentration-intensive work.

And it’s not just that interruptions are harmful. It’s also that distractions can be beneficial at the right time. Sometimes, when you’re stuck on a problem, taking a break is the right move. You hand off the problem to your subconscious mind, you answer a few emails or hop in IRC for a few minutes, and when you come back, the solution becomes obvious to you. But you can’t schedule that kind of ebb and flow to happen at the same time every week.

We allow the CPU to schedule I/O. We should allow programmers the same freedom. Likewise, we use distributed version control, and we get the most productivity out of distributed meetings.