在我的职业生涯中，可能发生在我身上最好的一件事就是让凯兰来管理我。我逗留了足够长的时间，看到凯兰的技术决策开始产生成果。我从中学到了很多，但我也从中学到了很多。我现在不可能成为编写数据驱动产品的工程师！如果凯兰没有在那里如此彻底地坚持技术选择的话。
离开Etsy后的一年里，我重新恢复了关心技术的能力。我的思想已经明确到可以连贯地写下来的程度。接下来是凯兰格式塔的升华，希望这只会让他稍微感到恐惧。
假设每家公司都能获得大约三种创新代币。你可以想怎么花就怎么花，但供应长期是固定的。在你达到一定的稳定性和成熟度后，你可能会得到更多，但总的趋势是高估你钱包里的东西。显然，这个模型是近似的，但我认为它有帮助。
如果你选择用NodeJS写网站，你只花了一个创新标记。如果你选择使用MongoDB，你只花了一个创新代币。如果你选择使用已经存在一年或更短时间的服务发现技术，你只花了一个创新代币。如果你选择编写自己的数据库，天哪，你有麻烦了。
如果你是一家javascript咨询公司或数据库公司，这些选择中的任何一个都可能是明智的。但你可能不是。你可能正在为一家公司工作，该公司至少表面上正在重新思考全球商业，或在网络上重新发明支付方式，或追求其他一些合适的史诗般的使命。在这种情况下，将任何有限的注意力投入到创新ssh上都是一个很好的失败方式。或者充其量只能推迟成功[1]。
什么算无聊？这有点棘手。“无聊”不应与“糟糕”混为一谈有一种技术既无聊又糟糕[2]。你不应该使用这些。但有很多技术选择既无聊又好，或者至少足够好。MySQL很无聊。博士后很无聊。PHP很无聊。Python很无聊。Memcached很无聊。乌贼很无聊。克朗很无聊。
无聊（如此受限）的好处在于，人们很好地理解了这些东西的功能。但更重要的是，他们的失败模式是众所周知的。任何了解我的人都会明白，我现在只是带着一种压倒性的不适感，才会援引唐·拉姆斯菲尔德的幽灵，但我必须这样做。
一个已知的未知是这样的：我们不知道当这个数据库达到100%CPU时会发生什么。
一个未知数是这样的：天哪，我们甚至没有想到编写统计数据会导致GC暂停。
这两个集合通常都是非空的，即使对于已经存在了几十年的技术来说也是如此。但对于闪亮的新技术来说，未知未知的数量要大得多，这一点很重要。
我毫无歉意地认为，偏向无聊的技术是件好事，但这不是唯一需要考虑的因素。技术选择不是孤立发生的。它们的范围涉及到您的整个团队、组织，以及从您的所有选择中产生的系统。
为公司添加技术是有成本的。作为一个抽象的陈述，这是显而易见的：如果我们已经在使用Ruby，那么将Python添加到混合中是不明智的，因为由此产生的复杂性将超过Python的边际效用。但不知何故，当我们谈论Python、Scala或MySQL和Redis时，人们会失去理智，放弃所有约束，开始疯狂地谈论如何使用最好的工具来完成这项工作。
简而言之，您的功能是将业务问题映射到涉及软件选择的解决方案空间。如果软件的选择真的没有包袱，你确实可以为你的各种问题挑选一大堆最好的工具。
但当然，行李是存在的。我们把行李称为“操作”，在较小程度上称为“认知开销”你必须监视这件事。你必须搞清楚单元测试。你需要知道的第一件事就是破解它。你需要一个初始化脚本。我可以在这里待上几天，所有这些加起来很快。
“工作的最佳工具”思维的问题在于，它对“最佳”和“工作”这两个词的看法是短视的你的工作就是让公司继续经营，该死的。而“最好”的工具就是对尽可能多的问题占据“最差”位置的工具。
基本上总是这样的，保持系统可靠运行的长期成本远远超过构建系统时遇到的任何不便。成熟且高效的开发人员明白这一点。
将这种推理简化为荒谬意味着选择Java，然后尝试在不使用任何其他东西的情况下实现一个网站。那太疯狂了。你需要一些方法来增加你的工具箱。
重要的第一步是承认这是一个过程和一次对话。新技术最终会在全公司范围内产生影响，因此增加技术是一个需要全公司可见性的决定。你的组织细节可能会迫使谈话进行，也可能会帮助开发人员在不与任何人交谈的情况下添加新的数据库和队列。无论如何，你必须设定文化期望，这是我们大家都在谈论的事情。
我推荐的最有价值的练习之一是考虑如何在不增加任何新东西的情况下解决眼前的问题。首先，提出这个问题应该能够发现“问题”是有人真的想使用这项技术的情况。如果是这种情况，你应该立即中止。
一小部分技术选择能走多远，这是令人惊讶的。在实践中，这个问题的答案几乎从来都不是“我们做不到”，它通常只是“嗯，我们可以做到，但这太难了”[4]。如果你认为你不能用你现在拥有的来实现你的目标，那么你可能只是没有足够的创造性思维。
准确地写下当前堆栈的哪些方面会让解决问题变得昂贵和困难，这是很有帮助的。这与之前的练习有关，但有细微的不同。
新的技术选择可能纯粹是加性的（例如：“我们还没有缓存，所以让我们添加memcached”）。但它们也可能重叠或替换您已经在使用的东西。如果是这样的话，您应该对将旧功能迁移到新系统设定明确的期望。政策通常应该是“我们致力于迁移”，并有一个建议的时间表。这一步的目的是将残骸保持在可管理的水平，并避免扩散局部最优解决方案。
这个过程并不令人望而生畏，也不太麻烦。有几个问题要作为家庭作业填写，然后开会讨论。我认为，如果一项新技术（或将在您的基础设施上创建的新服务）能够安然无恙地通过这项挑战，那么补充一句就可以了。
Polyglot编程销售时承诺，让开发人员完全自由地选择自己的工具将使他们更有效地解决问题。这充其量是对问题的幼稚定义，最糟糕的是有动机的推理。日常运营的繁重劳作会把你压死。
谨慎地选择技术给了工程头脑真正的自由：思考更大问题的自由。技术本身就是蛇油。
更新，2015年7月27日：我根据这篇文章写了一篇演讲。你可以在这里看到。
Etsy早年遭受了严重的痛苦。我们雇佣了一群Python程序员，并决定我们需要为他们在Python中找到一些可以做的事情，唯一想到的是创建一个毫无意义的中间层，需要多年的努力才能切断。同时，第90百分位搜索延迟约为两分钟。Etsy没有'；虽然没有失败，但它已经好几年没有发货了。因此，成功所需的时间比需要的时间更长。
我们经常随意地将厄运的无聊/糟糕交集称为“企业软件”，但这个术语可能不准确。
拉姆斯菲尔德这样说是有意或无意地暗示了苏格拉底悖论。苏格拉底在许多方面都是一个深思熟虑的人，而拉姆斯菲尔德不是。
根据我的经验，Etsy的活动提要就是一个很好的例子。当我们构建这个特性时，我们非常努力地将大部分Etsy整合到PHP、MySQL、Memcached和Gearman（一个PHP作业服务器）上。在该堆栈上实现该功能要比使用Redis（或者不使用）等工具复杂得多。但在该堆栈上构建活动提要是绝对可能的。
这个项目发生了一件令人惊讶的事情：几年来，我们的注意力转向了其他地方。在这段时间里，活动提要放大了20倍，而根本没有人观看。我们没有针对活动提要进行任何更改，但由于使用了共享平台，随着使用量的激增，一切都很顺利。简而言之，这是技术选择限制的长期好处。
这并不是一个绝对的立场——虽然memcached中存储的活动提要被认为是实用的，但在原始PHP中实现带刻面的全文搜索并不是#39；t、 所以Etsy使用Solr。