Choose boring technology: Dan McKinley's essay on innovation tokens

Three innovation tokens

In an essay published on March 30, 2015, Dan McKinley offers a simple budgeting model: every company gets about three "innovation tokens", and the supply stays fixed for a long while. Picking Node.js costs one; so does MongoDB, or service-discovery tech less than a year old. Writing your own database, he adds, means you are in trouble. Such choices can make sense for a JavaScript consultancy or a database company, but most teams are trying to rethink commerce or payments, and spending scarce attention on innovating infrastructure is a good way to fail — or at least to delay success. Extra tokens may arrive after a period of stability, though teams tend to overestimate the contents of their wallet.

Boring does not mean bad

The essay is careful about the word itself: "boring" should not be conflated with "bad". Some technology is both boring and bad, and there is no reason to use it. But MySQL, Postgres, PHP, Python, Memcached, Squid and Cron are boring and good enough. What makes them valuable is not only that their capabilities are well understood, but that their failure modes are. McKinley separates known unknowns — "we don't know what happens when this database hits 100% CPU" — from unknown unknowns — "it didn't occur to us that writing stats would cause GC pauses". Both sets are rarely empty, even for decades-old technology; for shiny new tools the second category is far larger.

Optimize globally

Technology choices do not happen in isolation, he writes; their scope touches the entire team and the system that emerges from their sum. Adding a technology carries "operations" and "cognitive overhead": someone has to monitor it, test it, write its init script. "Best tool for the job" thinking, in his reading, takes a myopic view of both words — the job is keeping the company in business, and the best tool occupies the "least worst" position across as many problems as possible. Keeping a system reliable, over the long term, he writes, costs far more than the inconveniences met while building it.

Adding something new, deliberately

New technology still enters the toolbox sometimes, and McKinley proposes a conversation rather than a ban: additions have company-wide effects, so they need company-wide visibility. The first exercise is to ask how the immediate problem would be solved without adding anything new — which also exposes cases where the real "problem" is that someone wants to try a tool. Migrations should come with a commitment and a timeline, to avoid accumulating locally optimal solutions. Etsy supplies both cautionary and encouraging examples: an early Python middle layer that took years to amputate, and activity feeds that ran for years on PHP, MySQL, Memcached and Gearman, scaling 20x while nobody was watching — because the stack was shared.