Doomed to Repeat It
Learning from the things we make over and over
Did you ever notice, wrote my friend Finn Smith via chat, how often we (meaning programmers) reinvent the same applications? We came up with a quick list: Email, Todo lists, blogging tools, and others. Do you mind if I write this up for Medium? I asked. I will credit you for the idea. Sure! he replied. Write away.
There’s always some big deal in email—in 2013 it was Mailbox, an app that made it easy to sort and process email. There was a long waiting list for people who wanted to download and use the software. It was like the cronut of apps. Later, Mailbox was acquired by Dropbox for about $100 million. People stopped talking about it after that.
The same year there was Gmail Inbox Tabs, which broadly pre-sorts your mail into categories like “primary,” “social,” “forums,” and so forth. This was very useful because it differentiated between email from people (high value) and email from organizations and mailing lists (lower value). It worried the organizations, who had based their future plans on the idea that you would always be forced to receive their emails. But Google decided, and that was that.
This year doesn’t yet have a contender for email-reinvention. Maybe Inbox, which is made by people who used to work at Dropbox, among others. Inbox lets you treat email as a platform and makes it easy for web programmers to do things with email. This makes sense because there are more web programmers than email programmers. But it’s not a consumer product as much as a tool for building consumer products, so it’s unlikely to really catch fire in the popular email imagination. (Also, peoplebox needbox to stopbox using “-box” as suffixbox.)
Those products are software solutions to “the problem of email” but there are cultural solutions, too. Many people just give up and declare email bankruptcy, meaning they erase all their email and start over. Others seek “inbox zero,” having filtered all of their emails into task-lists. You can even get an inbox zero merit badge. There’s even a mock-“Law of Software Envelopment,” attributed to the programmer and pizza-shop owner Jamie Zawinski in the 1990s, with origins at MIT. It goes: “Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”
Let’s take a brief look at the issues that are being discussed when people either make software about, or write blog posts about, email:
- There’s too much of it, it comes from too many places and it’s hard to sort it. (Gmail tabs, Mailbox)
- It becomes part of most applications. (Law of Envelopment)
- It works in its own way that is difficult to understand, unlike the web. (Inbox)
- It can overwhelm your life, and the perfect number of emails in your inbox is zero. (Inbox Zero, Bankruptcy)
That last one jumps out. Is there another form of communication besides email where the acknowledged goal is to hide all of the communication?Email has evolved into a weird medium of communication where the best thing you can do is destroy it quickly, as if every email were a rabid bat attacking your face. Yet even the tragically email-burdened still have a weird love for this particular rabid, face-attacking bat. People love to tweet about how overwhelming it all is. They write articles about email bankruptcy and proclaim their inbox zero status. Email is broken, everyone agrees, but it’s the devil we know. Besides, we’re just one app away from happiness. A tremendous amount of human energy goes into propping up the technological and cultural structure of email. It’s too big to fail.
In the video below the programmer Bret Victor, in 1970s-IBM Engineer mufti, talks about the future of programming; the conceit is that he’s talking as if it were 1972. It’s worth looking at a little of it even if you’re not a programmer, because it illustrates, entertainingly, that most of the core ideas and concepts of the modern digital era were very well understood by the late 1960s. Email started sending in 1971.
To-do Lists
One of the systems Victor talks about is in that speech is Doug Engelbart’s NLS system of 1968, which pioneered a ton of things—collaborative software, hypertext, the mouse—but deep, deep down was a to-do list manager. Since then the world of technology has never hurt for personal productivity tools. Every year or two there seems to be a new hotness: it was Remember the Milk for a while, and OmniFocus, and TaskPaper, and Asana. Asana’s tagline is “Teamwork without email.” And of course there are tons of productivity technologies that don’t involve a computer, including the “Getting Things Done” system, which tore through the Internet like wildfire for a few years—Inbox Zero is its legacy. Its influence can be felt throughout the world of software apps. There are systems of software development, where people sort their ambitions into use cases and take assignments at standup meetings, are another.
To-do list apps have become a sort of meta-technology. For example, when programmers come up with a new programming language or framework for the web—that is, when they build a new way to build things—they will be in need of a way to to demonstrate why their approach is better, and one way they do that is to write a to-do app. There’s even a website, ToDoMVC, where you can get all the graphics and assets you need to get started writing your own clone app; there are more than 60 different versions of the exact same to-do tool on that site, each written with its own framework or with its own approach (and these are just for the web; you can write to-do apps in any language). This way, someone shopping for a framework can figure out which one suits their needs. To-do lists are a sort of meta-idea—so well understood and accepted that it’s become a shorthand, a bit of common knowledge that everyone can share.
The implications of a to-do list are very similar to the implications of software development. A task can be broken into a sequence, each of those items can be executed in turn. Maybe programmers love to do to-do lists because to-do lists are like programs. The phrase “Yet another” is part of countless acronyms—yet another markup language (YAML), yet another JSON library (YASL), yet another hierarchical officious oracle (Yahoo!).
What are the other things that we make again and again? Commenting systems, discussion forums, apps that let you manage all of your communication in one place, collaborative writing tools, blogging platforms—what else? (Use the comment system of this blogging platform to weigh in if it suits you.)
Communication must become total and conscious before we can stop it. —William S. Burroughs, 1962
Other Things
There are other things that we invent over and over. Markup languages, for example, that let us wrap up data and give it meaning as we send it from computer to computer. I will save the reader the agony of a multi-decade recap, and just spew acronyms: S-expressions, XML, JSON, YAML, HTML1-5, and hundreds more—all are politically-charged, vigorously defended, not-fully-compatible attempts to resolve the question of “how to share information between computers.” Then there is Greenspun’s tenth rule, which holds that:
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
The idea of it being that the qualities (or maybe the qualia) of the programming language Lisp—its simplicity and its approach to processing lists of things in the memory of a computer—are so fundamental that they are emergent. If you write a big program, you’ll reinvent Lisp. If you write a big program, it will read email. If you are a programmer, you will find yourself drawn to to-do lists. And then you will talk about these things, because they are the touchstones of our shared culture of technology, with attendant rituals.
It’s not email bankruptcy; it’s email baptism. Sinbox Zero.
Very little feels as good as organizing all of your latent tasks into a hierarchical lists with checkboxes associated. Doing the work, responding to the emails—these all suck. But organizing it is sweet anticipatory pleasure.
Working is hard, but thinking about working is pretty fun. The result is the software industry.
It’s not that email is broken or productivity tools all suck; it’s just that culture changes. People make email clients or to-do list apps in the same way that theater companies perform Shakespeare plays in modern dress. “Email” is our Hamlet. “To-do apps” are our Tempest.
The developer raises up the great sword of technology and brings it down upon the plinth of culture—and the sword shatters. But never mind; we can go back to the forge to make a bigger, better sword for retina displays. And as we craft it we whisper that eternal prayer for the comfort of list-makers: This time will be different.
