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.我职业生涯中最棒的一件事，莫过于由 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 [1].如果你是一家 JavaScript 咨询公司或数据库公司，这些选择或许还算合理。但你大概率不是。你可能正在为一家旨在重塑全球商业、革新网络支付或追求某种史诗级使命的公司工作。在这种背景下，将有限的精力浪费在创新 SSH 上，是通往失败的捷径；或者往好里说，只会延误成功 [1]。
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 [2]. 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.什么才算“枯燥”？这有点微妙。“枯燥”不应与“糟糕”混为一谈。有些技术既枯燥又糟糕 [2]，那种你当然不该用。但有很多技术选择既枯燥又优秀，或者至少是“足够好”。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.枯燥（在一定约束下）的好处在于，人们对这些技术的性能了如指掌。更重要的是，大家对它们的故障模式也心知肚明。熟悉我的人都知道，我只有在极度不适的情况下才会召唤唐·拉姆斯菲尔德（Don Rumsfeld）的幽灵，但现在我不得不这么做。
When choosing technology, you have both known unknowns and unknown unknowns [3].在选择技术时，你既会遇到“已知的未知”，也会遇到“未知的未知” [3]。
- A known unknown is something like: we don’t know what happens when this database hits 100% CPU.“已知的未知”是指：我们不知道当这个数据库 CPU 达到 100% 时会发生什么。
- An unknown unknown is something like: geez it didn’t even occur to us that writing stats would cause GC pauses.“未知的未知”是指：天哪，我们甚至没想到编写统计数据会导致垃圾回收（GC）停顿。
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.这两类情况通常都不为空，即使是对于存在了几十年的技术也是如此。但对于那些闪亮的新技术，其“未知的未知”规模要大得多，这一点至关重要。
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.你的核心职能是将业务问题映射到包含软件选择的解决方案空间中。如果这些软件选择真的没有“包袱”，你确实可以为各种问题挑选一大堆局部最优的工具。
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 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.如果将这种逻辑推向极致，就意味着只选 Java，然后尝试只用它来实现整个网站。那简直是疯了。你需要一些途径来扩充你的工具箱。
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. 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 solve your immediate problem without adding anything new. First, posing this question should detect the situation where the “problem” is that someone really wants to use the technology. If that is the case, you should immediately abort.我推荐的最有价值的练习之一是：思考如何在不添加任何新东西的情况下解决当下的问题。首先，提出这个问题可以识别出那些仅仅是因为“想用新技术”而产生的问题。如果是这种情况，你应该立即打消这个念头。
It can be amazing how far a small set of technology choices can go. The answer to this question in practice is almost never “we can’t do it,” it’s usually just somewhere on the spectrum of “well, we could do it, but it would be too hard” [4]. If you think you can’t accomplish your goals with what you’ve got now, you are probably just not thinking creatively enough.一套有限的技术选择能发挥的效用往往令人惊叹。在实践中，这个问题的答案几乎从不是“我们做不到”，通常只是处于“嗯，我们可以做到，但太难了”这一区间的某个位置 [4]。如果你认为仅凭现有手段无法实现目标，那很可能只是你思考得不够有创意。
It’s helpful to write down exactly what it is about the current stack that makes solving the problem prohibitively expensive and difficult. This is related to the previous exercise, but it’s subtly different.写下当前技术栈中究竟是什么导致解决问题的成本过高或难度过大，这很有帮助。这与上一个练习相关，但又略有不同。
New technology choices might be purely additive (for example: “we don’t have caching yet, so let’s add memcached”). But they might also overlap or replace things you are already using. If that’s the case, you should set clear expectations about migrating old functionality to the new system. The policy should typically be “we’re committed to migrating,” with a proposed timeline. The intention of this step is to keep wreckage at manageable levels, and to avoid proliferating locally-optimal solutions.新技术选择可能是纯粹的增量（例如：“我们还没有缓存，所以加个 Memcached”）。但它们也可能与现有技术重叠或产生冲突。如果是这种情况，你应该明确迁移旧功能到新系统的预期。策略通常应该是“我们承诺迁移”，并附带拟定的时间表。此步骤旨在将混乱控制在可管理的范围内，并避免局部最优方案的泛滥。
This process is not daunting, and it’s not much of a hassle. It’s a handful of questions to fill out as homework, followed by a meeting to talk about it. I think that if a new technology (or a new service to be created on your infrastructure) can pass through this gauntlet unscathed, adding it is fine.这个过程并不令人生畏，也不会带来太多麻烦。只需要完成几项作业式的问题，然后开个会讨论一下。我认为，如果一项新技术（或要在基础设施上创建的新服务）能顺利通过这一关，那么引入它是没问题的。
Just Ship.只管发布。
Polyglot programming is sold with the promise that letting developers choose their own tools with complete freedom will make them more effective at solving problems. This is a naive definition of the problems at best, and motivated reasoning at worst. The weight of day-to-day operational toil this creates crushes you to death.“多语言编程”的卖点是：让开发者自由选择工具能让他们更高效地解决问题。往好了说，这是对问题本质的天真定义；往坏了说，这是动机性的推理。它所带来的日常运维负担足以将你压垮。
Mindful choice of technology gives engineering minds real freedom: the freedom to contemplate bigger questions. Technology for its own sake is snake oil.审慎的技术选择能赋予工程大脑真正的自由：思考更宏大问题的自由。为了技术而技术，无异于推销蛇油。
Update, July 27th 2015: I wrote a talk based on this article. You can see it here.更新，2015 年 7 月 27 日：我基于这篇文章做了一次演讲，你可以在这里查看。
- Etsy in its early years suffered from this pretty badly. We hired a bunch of Python programmers and decided that we needed to find something for them to do in Python, and the only thing that came to mind was creating a pointless middle layer that required years of effort to amputate. Meanwhile, the 90th percentile search latency was about two minutes. Etsy didn't fail, but it went several years without shipping anything at all. So it took longer to succeed than it needed to.
- We often casually refer to the boring/bad intersection of doom as “enterprise software,” but that terminology may be imprecise.
- In saying this Rumsfeld was either intentionally or unintentionally alluding to the Socratic Paradox. Socrates was by all accounts a thoughtful individual in a number of ways that Rumsfeld is not.
-
A good example of this from my experience is Etsy’s activity feeds. When we built this feature, we were working pretty hard to consolidate most of Etsy onto PHP, MySQL, Memcached, and Gearman (a PHP job server). It was much more complicated to implement the feature on that stack than it might have been with something like Redis (or maybe not). But it is absolutely possible to build activity feeds on that stack.
An amazing thing happened with that project: our attention turned elsewhere for several years. During that time, activity feeds scaled up 20x while nobody was watching it at all. We made no changes whatsoever specifically targeted at activity feeds, but everything worked out fine as usage exploded because we were using a shared platform. This is the long-term benefit of restraint in technology choices in a nutshell.
This isn’t an absolutist position--while activity feeds stored in memcached was judged to be practical, implementing full text search with faceting in raw PHP wasn't. So Etsy used Solr.