或许在我的职业生涯中最好的事情就是让Kellan成为我的主管。我坚持了很长时间，足以看到Kellan的技术决策开始结出硕果。我从中学到了很多，但我也因此学到了很多。如果没有Kellan在技术选择上如此完美地“降落”，我就不可能有机会成为写了数据驱动产品现在！的工程师。
一如既往地鼓舞人心。
自从离开Etsy一年以来，我恢复了对技术的关注。现在我的思绪已经凝聚到可以清晰地写下来的程度。接下来是Kellan的精华提炼，希望对他的惊吓程度不会太大。
假设每个公司都有大约三个创新代币。你可以随意花这些代币，但供应在很长一段时间内是固定的。在你达到一定程度的稳定和成熟之后，你可能会得到更多的代币，但一般来说，人们容易高估自己的财富。显然这个模型是近似的，但我认为它很有帮助。
如果你选择用NodeJS编写你的网站，你刚刚花掉了一个创新代币。如果你选择使用MongoDB，你刚刚花掉了一个创新代币。如果你选择使用存在不到一年的服务发现技术，你刚刚花掉了一个创新代币。如果你选择编写自己的数据库，哦天哪，你有麻烦了。
这些选择中的任何一个对于JavaScript咨询公司或数据库公司来说都可能是明智的。但你可能不是。你可能在为一家至少表面上重新思考全球商务或重新定义网络支付或追求其他同样宏伟使命的公司工作。在这种情况下，将你有限的注意力投入到创新ssh上是失败的绝佳途径。或者至少，会拖延成功[1]。
什么算作无聊呢？这有点棘手。“无聊”不应与“糟糕”混为一谈。市面上有一些既无聊又糟糕的技术[2]。你不应该使用其中任何一种。但有很多技术选择既无聊又好，或者至少足够好。MySQL 是无聊的。Postgres 是无聊的。PHP 是无聊的。Python 是无聊的。Memcached 是无聊的。Squid 是无聊的。Cron 是无聊的。
无聊的好处（在一定程度上）是这些东西的功能众所周知。但更重要的是，它们的失效模式也众所周知。熟知我的人会明白，现在我提到唐·拉姆斯菲尔德（Don Rumsfeld）这个幽灵，是带着一种压倒性的不安感。
说清楚点，*** 就是这家伙。
在选择技术时，你既有已知未知，也有未知未知[3]。
- 已知未知就像是：我们不知道当这个数据库的 CPU 使用率达到 100% 时会发生什么。
- 未知未知就像是：天哪，我们甚至没想到写入统计数据会导致垃圾回收暂停。
即使对于存在了几十年的技术，这两类通常都是非空的。但是对于闪亮的新技术，未知未知的数量级要大得多，这一点很重要。
我毫不犹豫地认为，偏爱无聊技术是一件好事，但这并不是唯一需要考虑的因素。技术选择并非孤立发生。它们的范围涉及到整个团队、组织以及由你的所有选择总和形成的系统。
为公司引入技术是要付出代价的。抽象地说，这是显而易见的：如果我们已经在使用 Ruby，再加入 Python 似乎不明智，因为由此产生的复杂性将抵消 Python 的边际效用。但当我们讨论 Python 和 Scala 或 MySQL 和 Redis 时，人们会失去理智，抛弃所有约束，并开始狂热地谈论使用最合适工作的工具。
你的职能简述是将业务问题映射到一个涉及软件选择的解决方案空间。如果软件选择真的没有包袱，那么你确实可以为你的一系列问题选择一大堆局部最优的工具。
问题技术解决方案
在选择成本很低的世界里，你可能会选择技术：“为工作选择合适的工具。”
但当然，包袱是存在的。我们称这种包袱为“运维”以及在较小程度上的“认知负担”。你需要监控这个东西。你必须弄清楚单元测试。你需要了解一些关于它的基本信息，以便在上面进行修改。你需要一个初始化脚本。我可以在这里继续讲很多天，所有这些都会迅速累加起来。
问题技术解决方案
在运维成为严重问题的世界里（即“现实”）选择技术的方式。
“最佳工具”思维的问题在于，它对“最佳”和“工作”这两个词的理解过于短视。你的工作是让公司维持运营，该死的。而“最佳”工具就是那个在尽可能多的问题中处于“最不糟糕”位置的工具。
基本上总是这样的，保持系统可靠运行的长期成本远远超过了你在构建过程中遇到的任何不便。成熟且高效的开发人员明白这一点。
将这种推理进行到极致，就意味着选择 Java，然后试图在不使用任何其他东西的情况下实现一个网站。那将是疯狂的。你需要一些方法将新技术添加到你的工具箱中。
重要的第一步是承认这是一个过程，一个对话。新技术最终会对整个公司产生影响，因此添加技术是一个需要公司范围内可见性的决策。你的组织特点可能会促使这个对话，或者它们可能会让开发人员在不与任何人交流的情况下添加新的数据库和队列。无论如何，你必须设定文化期望，即这是我们大家都要谈论的事情。
我在这里推荐的最有价值的练习之一是考虑在不添加任何新技术的情况下如何解决你当前的问题。首先，提出这个问题应该检测到这种情况，即“问题”是有人真的想使用这项技术。如果是这种情况，你应该立即中止。
我刚刚观看了一个关于图形数据库的网络研讨会，我们应该尝试一下。
令人惊讶的是，一小部分技术选择可以走多远。实际上，这个问题的答案几乎从来不是“我们做不到”，而通常只是在“嗯，我们可以做到，但难度太大了”[4] 的范围内。如果你认为你无法用现有的技术实现你的目标，那么你可能只是没有足够创造性地思考问题。
有助于**详细写下现有技术栈使解决问题变得极其昂贵和困难的原因。**这与之前的练习有关，但它们之间存在微妙的差别。
新技术选择可能是纯粹的附加（例如：“我们还没有缓存，所以让我们添加 memcached”）。但它们也可能与你已经在使用的东西重叠或替代。如果是这种情况，你应该**对将旧功能迁移到新系统设定明确的期望。**政策通常应该是“我们致力于迁移”，并提出建议的时间表。这个步骤的目的是将残骸保持在可管理的水平，并避免在局部产生最优解。
这个过程并不令人生畏，也不会带来很多麻烦。这是一些需要作为作业填写的问题，然后召开一个会议讨论它。我认为，如果一项新技术（或者要在你的基础设施上创建的新服务）能够毫发无伤地通过这个关卡，那么添加它是可以的。
多语言编程的推广承诺是，让开发人员在选择工具时拥有完全的自由，这将使他们在解决问题时更有效。这种对问题的定义充其量是天真的，最坏的情况是出于动机的推理。这种日常运营toil带来的负担会压垮你。
在技术选择上保持谨慎可以让工程师的头脑真正自由：拥有思考更大问题的自由。技术本身就是蛇油。
更新于2015年7月27日：我根据这篇文章写了一个演讲。你可以在这里观看。
- 早期的 Etsy 因此受到了相当严重的影响。我们雇佣了一群 Python 程序员，决定让他们用 Python 做些什么，唯一能想到的就是创建一个毫无意义的中间层，需要数年的努力才能截断。与此同时，搜索延迟的90百分位数大约是两分钟。Etsy 没有失败，但它有好几年时间没有发布任何东西。所以成功的时间比预期要长。
- 我们经常随意地将无聊/糟糕的交叉点称为“企业软件”，但这个术语可能不够准确。
- 在这样说时，拉姆斯菲尔德或有意或无意地引用了苏格拉底悖论。在很多方面，苏格拉底都被认为是一个与拉姆斯菲尔德不同的富有思想的人。
- 一个很好的例子是 Etsy 的活动信息流。当我们构建这个功能时，我们努力将大部分 Etsy 集成到 PHP、MySQL、Memcached 和 Gearman（一个 PHP 作业服务器）上。在这个技术栈上实现这个功能比使用像 Redis（或者也许不是）这样的东西要复杂得多。但在这个技术栈上绝对可以构建活动信息流。
这个项目发生了一件令人惊奇的事情：我们的注意力在接下来的几年里转向了其他地方。在此期间，活动信息流在 没有人关注的情况下 扩展了 20 倍。我们没有对活动信息流进行任何特定的更改，但由于我们使用了共享平台，所以在使用量爆炸时一切都运行得很好。简而言之，这就是在技术选择上保持克制所带来的长期利益。
这并非绝对主义立场 — 尽管将活动信息流存储在 memcached 中被认为是实际的，但在原始 PHP 中实现带分面的全文搜索是不现实的。所以 Etsy 使用了 Solr。