Choose Boring Technology (2015)

选择无聊的技术 (2015)

Probably the single best thing to happen to me in my career was having had Kellan placed in charge of me. I stuck around long enough to see Kellan’s technical decisionmaking start to bear fruit. I learned a great deal from this, but I also learned a great deal as a result of this. I would not have been free to become the engineer that wrote Data Driven Products Now! if Kellan had not been there to so thoroughly stick the landing on technology choices. Being inspirational as always. 在我职业生涯中，发生过最棒的一件事就是由 Kellan 来负责管理我。我待得足够久，亲眼见证了 Kellan 的技术决策开始结出硕果。我从中获益良多，也因此学到了很多东西。如果不是 Kellan 在技术选型上做得如此稳健，我根本没有余力成为那个写出《Data Driven Products Now!》的工程师。他一如既往地鼓舞人心。

In the year since leaving Etsy, I’ve resurrected my ability to care about technology. And my thoughts have crystallized to the point where I can write them down coherently. What follows is a distillation of the Kellan gestalt, which will hopefully serve to horrify him only slightly. 离开 Etsy 的这一年里，我重新找回了对技术的热情。我的想法也已沉淀到可以清晰地记录下来的程度。以下是对 Kellan 思想精髓的提炼，希望这只会让他感到一点点惊恐。

Embrace Boredom

拥抱无聊

Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet. Clearly this model is approximate, but I think it helps. 假设每家公司大约有三个“创新代币”。你可以随心所欲地使用它们，但供应量在很长一段时间内是固定的。当你达到一定的稳定性和成熟度后，或许能再获得几个，但人们通常倾向于高估自己钱包里的余额。显然这个模型只是个近似值，但我认为它很有帮助。

If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that’s existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you’re in trouble. 如果你选择用 NodeJS 编写网站，你就花掉了一个创新代币。如果你选择使用 MongoDB，你就花掉了一个创新代币。如果你选择使用存在时间不到一年的服务发现技术，你就花掉了一个创新代币。如果你选择编写自己的数据库，天哪，那你就有麻烦了。

Any of those choices might be sensible if you’re a javascript consultancy, or a database company. But you’re probably not. You’re probably working for a company that is at least ostensibly rethinking global commerce or reinventing payments on the web or pursuing some other suitably epic mission. In that context, devoting any of your limited attention to innovating ssh is an excellent way to fail. Or at best, delay success. 如果你是一家 JavaScript 咨询公司或数据库公司，这些选择或许是合理的。但你很可能不是。你可能正在为一家公司工作，这家公司至少表面上是在重新思考全球商业、重塑网络支付，或者追求其他某种宏大的使命。在这种背景下，将你有限的精力投入到 SSH 的创新上，是走向失败的绝佳途径。或者往好了说，这只会延误成功。

What counts as boring? That’s a little tricky. “Boring” should not be conflated with “bad.” There is technology out there that is both boring and bad. You should not use any of that. But there are many choices of technology that are boring and good, or at least good enough. MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring. 什么算“无聊”？这有点棘手。“无聊”不应与“糟糕”混为一谈。市面上确实存在既无聊又糟糕的技术，你当然不应该使用它们。但也有许多既无聊又好用，或者至少足够好用的技术选择。MySQL 是无聊的，Postgres 是无聊的，PHP 是无聊的，Python 是无聊的，Memcached 是无聊的，Squid 是无聊的，Cron 也是无聊的。

The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood. Anyone who knows me well will understand that it’s only with a overwhelming sense of malaise that I now invoke the spectre of Don Rumsfeld, but I must. To be clear, fuck this guy. When choosing technology, you have both known unknowns and unknown unknowns. 无聊（在上述限制下）的好处在于，这些技术的能力是众所周知的。更重要的是，它们的故障模式也是众所周知的。了解我的人都知道，我只有在极度不适的情况下才会搬出唐·拉姆斯菲尔德（Don Rumsfeld）的幽灵，但我必须这么做。声明一下，去他的。在选择技术时，你既会遇到“已知的未知”，也会遇到“未知的未知”。

A known unknown is something like: we don’t know what happens when this database hits 100% CPU. An unknown unknown is something like: geez it didn’t even occur to us that writing stats would cause GC pauses. Both sets are typically non-empty, even for tech that’s existed for decades. But for shiny new technology the magnitude of unknown unknowns is significantly larger, and this is important. “已知的未知”是指：我们不知道当数据库 CPU 达到 100% 时会发生什么。“未知的未知”是指：天哪，我们甚至没料到写入统计数据会导致垃圾回收（GC）停顿。这两类集合通常都不为空，即使是存在了几十年的技术也是如此。但对于闪亮的新技术来说，“未知的未知”规模要大得多，这一点至关重要。

Optimize Globally

全局优化

I unapologetically think a bias in favor of boring technology is a good thing, but it’s not the only factor that needs to be considered. Technology choices don’t happen in isolation. They have a scope that touches your entire team, organization, and the system that emerges from the sum total of your choices. Adding technology to your company comes with a cost. 我毫不掩饰地认为，偏向无聊的技术是一件好事，但这并不是唯一需要考虑的因素。技术选择并非孤立存在。它们的范围触及整个团队、组织，以及由你所有选择的总和所构成的系统。向公司引入新技术是有成本的。

As an abstract statement this is obvious: if we’re already using Ruby, adding Python to the mix doesn’t feel sensible because the resulting complexity would outweigh Python’s marginal utility. But somehow when we’re talking about Python and Scala or MySQL and Redis people lose their minds, discard all constraints, and start raving about using the best tool for the job. 作为一个抽象的陈述，这显而易见：如果我们已经在用 Ruby，再引入 Python 并不明智，因为由此产生的复杂性将超过 Python 的边际效用。但不知为何，当谈到 Python 和 Scala，或者 MySQL 和 Redis 时，人们就会失去理智，抛弃所有约束，开始狂热地谈论“为工作选择最好的工具”。

Your function in a nutshell is to map business problems onto a solution space that involves choices of software. If the choices of software were truly without baggage, you could indeed pick a whole mess of locally-the-best tools for your assortment of problems. The way you might choose technology in a world where choices are cheap: “pick the right tool for the job.” But of course, the baggage exists. 简而言之，你的职责是将业务问题映射到包含软件选择的解决方案空间中。如果软件选择真的没有负担，你确实可以为各种问题挑选一堆局部最优的工具。在选择成本低廉的世界里，你可能会这样选择技术：“为工作选择合适的工具”。但当然，负担是真实存在的。

We call the baggage “operations” and to a lesser extent “cognitive overhead.” You have to monitor the thing. You have to figure out unit tests. You need to know the first thing about it to hack on it. You need an init script. I could go on for days here, and all of this adds up fast. The way you choose technology in the world where operations are a serious concern (i.e., “reality”). 我们称这种负担为“运维”，在较小程度上也称为“认知开销”。你必须监控它，必须搞定单元测试，必须了解它的基本原理才能进行开发，还需要编写初始化脚本。我可以列举几天几夜，所有这些加起来增长得很快。在运维是一个严重问题的世界（即“现实世界”）里，你必须这样选择技术。

The problem with “best tool for the job” thinking is that it takes a myopic view of the words “best” and “job.” Your job is keeping the company in business, god damn it. And the “best” tool is the one that occupies the “least worst” position for as many of your problems as possible. It is basically always the case that the long-term costs of keeping a system working reliably vastly exceed any inconveniences you encounter while building it. Mature and productive developers understand this. “为工作选择最好的工具”这种思维的问题在于，它对“最好”和“工作”这两个词的理解太短视了。该死的，你的工作是让公司活下去。而“最好”的工具，是那些能为你尽可能多的问题提供“最不坏”解决方案的工具。事实基本总是这样：长期维持系统可靠运行的成本，远超你在构建它时遇到的任何不便。成熟且高效的开发者都明白这一点。

Choose New Technology, Sometimes

有时，选择新技术

Taking this reasoning to its reductio ad absurdum would mean picking Java, and then trying to implement a website without using anything else at all. And that would be crazy. You need some means to add things to your toolbox. An important first step is to acknowledge that this is a process, and a conversation. New tech eventually has company-wide effects, so adding tech is a decision that requires company-wide visibility. 如果把这种推理推向极致，就意味着只选 Java，然后试图不使用任何其他东西来构建网站。那太疯狂了。你需要一些方法来向工具箱中添加新东西。第一步重要工作是承认这是一个过程，也是一场对话。新技术最终会产生全公司范围的影响，因此引入新技术是一个需要全公司可见性的决策。

Your organizational specifics may force the conversation, or they may facilitate developers adding new databases and queues without talking to anyone. One way or another you have to set cultural expectations that this is something we all talk about. One of the most worthwhile exercises I recommend here is to consider how you would… 你的组织特性可能会强制进行这种对话，也可能导致开发者在不与任何人沟通的情况下就引入新的数据库和队列。无论如何，你必须建立一种文化预期：这是我们所有人都要讨论的事情。我在这里推荐的最有价值的练习之一，是思考你将如何……