Uber核心平台技术最初押宝Thrift和Mesos，这种两种技术后来分别被gRPC和Kubernetes主流技术替代。
当初您做出技术路线决策的上下文已经时非今日可比，问题：技术决策的上下文半衰期是多少？多长时间你需要重新检查你当初决策的上下文是否已经失效？Will Demaine提出一些建议。
“大多数设计活动都需要不断做出选择。这些选择中的许多可能不仅仅是设计决定；而是其他选择。这也可能是设计师对自己的未来做出的个人决定。”
— 引用“康韦定律”论文
在Monzo公司，我们团队进行的许多项目都涉及对服务平台的根本性更改，有时这意味着消除了“ Monzo特定的怪异现象”。我们通常的目标是使事物尽可能地标准化流行化，通常编程技术采取社区集中度很高的热门技术。
当你创业建立公司时，您必须押注技术，有时您会选择错误的人。有时，没有合适的东西可用，您必须自己构建它。这没关系。但是，当技术领域的环境或上下文发生变化时，重新评估当初这些决定就很重要。沉没成本谬误在这里应该是您的首要考虑因素。
当变换技术路线时，“当我们已有Y技术并且易于学习时，是否值得采用X？”。这是一个公平的问题，很难回答。
选择几种平等竞争技术中的一种不是问题，但是当整个社区开始围绕其中一种技术开始集中而您却没有使用它这种技术时，就成问题了。
如果您从自己的定特定解决方案中得不到任何好处，且又不想换掉它，那么你会持续承担债务。您等待的时间越长，您的路径分歧就越大，迁移就变得越困难。
如果您今天理论上就可以进行明确的选择，那么这表明您至少应该考虑迁移到该技术，这是一个很好的指示。需要明确的是，过去支持错误的技术路径没有任何耻辱，没有人能预测事情会如何发展。
那么，您到底是否应该迁移吗？在大多数情况下，似乎人们是基于*当前*状态而不是*将来*状态做出决定。如果我们有些怪异，可以很容易地说“但是我们都已经习惯了，新人们可以很快地学习它”。但是，如果您是一个成长中的组织，那么拥有这种怪异上下文的人们很快就可以成为少数派。我称其为工程组织的“上下文半衰期”。
可以这样想：在您公司的整个生命周期中，最终需要了解此系统的“所有人”中，大多数人是否还在公司工作？
一些快速模型数据可以向您展示如何消除公司特有的怪异现象：拥有250名员工，年增长率为30％，人员流失率为10％，组织中50％的工程师只需花2年多的时间就可以使原始决策的上下文背景零化。拥有不到100名工程师，20％的增长和10％的损耗，这仅用了3年多的时间。
当我加入Uber时，我们有100名工程师，并且在2年的时间内以惊人的速度增长了惊人的400％。这意味着两年后，最初的团队仅占工程团队的3％。
有了这些数字，很明显可以看出，投资于消除“怪异”将是一个不错的选择。Uber更换了平台的核心部分，这使成千上万的新工程师可以加入，而无需熟悉那些衰落的技术。
相关：
用于押宝的方法论：Kent Beck的3X模型是什么？