退屈な技術を選べ (2015)

• 新しい技術の導入は抑制し、実績のある技術(boring technology) を優先して採用することが、会社の長期的な成功に有利
• すべての会社は約 3つのイノベーショントークン(innovation tokens) しか持っておらず、NodeJS・MongoDB・新興ツールを選ぶたびに1つずつ消費する
• 実績のある技術は 機能と障害パターン(failure modes) がよく知られているため、新興技術特有の 未知の未知(unknown unknowns) のリスクが小さい
• 技術選定はチーム・組織全体に影響し、運用負荷と認知負荷のため、「適材適所の最良のツール」よりも 複数の問題に幅広く無難に使えるツール のほうが有利
• 慎重な技術選定はエンジニアに より大きな問題へ集中する自由 を与え、技術そのもののための技術には意味がない

---

退屈さを受け入れる (Embrace Boredom)

• すべての会社は約 3つのイノベーショントークン(innovation tokens) を持ち、その供給量はしばらく固定される — 安定性と成熟度を確保すれば多少は増えるかもしれないが、保有量を過大評価しがち
• NodeJSでWebサイトを書くこと、MongoDB を使うこと、リリースから1年未満のサービスディスカバリ技術を採用することは、それぞれイノベーショントークンを1つ消費し、自前でデータベースを書くのは大惨事になりうる
  • こうした選択は、JavaScriptコンサルティング会社やデータベース企業であれば妥当かもしれないが、ほとんどの企業はグローバルコマースを再定義したりWeb決済を作り直したりするような大きな使命を追っている — ssh のような領域での革新に限られた注意力を注ぐのは、失敗か成功の遅延への近道
• 「退屈(boring)」は「悪い(bad)」と同義ではなく、退屈でしかも悪い技術も存在する — 退屈だが十分に良い例として MySQL, Postgres, PHP, Python, Memcached, Squid, Cron がある
• 退屈な技術の利点は、機能(capabilities) だけでなく 障害パターン(failure modes) までよく理解されている点にある
• 技術選定には known unknowns（例: データベースがCPU使用率100%に達したときどう動くか不明）と unknown unknowns（例: 統計記録がGC停止を引き起こすとは想定していなかったケース）が共存し、新興技術ほど unknown unknowns の規模ははるかに大きい

全体最適化を行う (Optimize Globally)

• 退屈な技術を好むのは良いバイアスだが、唯一の考慮事項ではなく、技術選定はチーム・組織・システム全体に及ぶ スコープ(scope) を持つ
• 技術の追加にはコストが伴う — すでにRubyを使っているのにPythonを足せば複雑性が限界効用を上回るが、Python vs Scala、MySQL vs Redis の議論では制約を忘れて 「適材適所の最良のツール(best tool for the job)」 を叫びがち
• 仕事の本質は ビジネス上の問題をソフトウェア選択の解空間に写像すること であり、選択に負担がなければ問題ごとに局所最適なツールを選べるが、現実には負担がある
  • その負担とは 運用(operations)、そしてそれよりやや小さい 認知負荷(cognitive overhead) — 監視、単体テスト、修正に必要な知識、initスクリプトなどが急速に積み上がる
• 「適材適所の最良のツール」という考え方の問題は、「最良」と「仕事」を近視眼的に捉えること — 本当の仕事は会社を存続させることであり、「最良」のツールとは、できるだけ多くの問題において 最もましな(least worst) 位置を占めるツール
• システムを安定して維持する 長期コスト は、構築中に感じる不便さを圧倒し、成熟した生産的な開発者はそれを理解している

ときには新しい技術を選ぶ (Choose New Technology, Sometimes)

• この論理を極端に突き詰めると、WebサイトをJavaだけで実装することになってしまい非現実的 — ツールボックスに新しい道具を加える手段が必要
• 新しい技術はいずれ全社的な影響を及ぼすため、その追加は 全社的な可視性(company-wide visibility) を要する意思決定 — 「これは私たち全員で一緒に議論する事柄だ」という文化的期待を設定する必要がある
• 最も勧めたい実践は、新しい技術を追加せずに目の前の問題をどう解くか を自問すること — 「問題」の実体が、単に誰かがその技術を使いたいだけという状況を見抜けるし、その場合は即座に中止できる
  • 少ない数の技術選択だけでも遠くまで進めるし、実際の答えは「できない」ではなく、たいてい「できるが難しすぎる」程度 — 現在のリソースで目標達成が不可能だと感じるなら、十分に創造的に考えていない可能性が高い
• 現在のスタックでその問題を解くのが、なぜ過度に高コストで難しいのかを 明確に記録 しておくと役立つ
• 新しい技術の選択は 純粋な追加型（例: キャッシュがないのでmemcachedを追加）であることもあれば、既存のものと重複したり置き換えたりすることもある — 置き換え型なら、既存機能のマイグレーション について明確な期待設定が必要であり、方針は通常、提案スケジュールとともに「移行を約束する」という形になる
  • 意図は残骸を管理可能な水準に保ち、局所最適な解決策の乱立を防ぐこと
• この手順はそれほど重くなく、課題として埋めるいくつかの質問と、それを議論する会議を1回設けるだけ — 新しい技術や新しいサービスがこの関門を無事に通過するなら、追加は妥当

とにかく出荷する (Just Ship)

• ポリグロットプログラミング(polyglot programming) は、開発者に完全なツール選択の自由を与えれば問題解決がより効果的になる、という約束で売られるが、これは良くてもナイーブな問題設定であり、悪ければ後付けの理屈にすぎない — 日々の運用の toil が開発者を押しつぶす
• 慎重な技術選定こそがエンジニアに より大きな問いを考える自由 を与え、技術それ自体のための技術はまやかし(snake oil)

Etsyの事例 (脚注)

• Etsyは初期にこの問題で大いに苦しんだ — Python プログラマを多数採用したあと、やることを探した結果、無意味な中間レイヤーを作ってしまい、それを取り除くのに何年もかかった / 同時に検索の90パーセンタイル遅延は約2分 — Etsyは失敗こそしなかったが、何年ものあいだ何も出荷できず、成功が遅れた
• 退屈でしかも悪い技術の共通部分をしばしば "enterprise software" と呼ぶが、正確ではないかもしれない
• Etsyの activity feeds の事例 - その大部分をPHP、MySQL、Memcached、Gearmanで統一していた時期に実装 / Redisのようなツールで作るより実装ははるかに複雑だったが、そのスタックでも十分に構築可能だった
  • その後何年も関心が別の場所へ移るあいだに、activity feeds の利用量は 20倍 に増えたが、共有プラットフォーム のおかげで追加の変更なしに正常に動作した — 技術選定において節度がもたらす長期的な利点
  • ただし絶対主義ではない — memcachedベースの activity feeds は実用的だと判断した一方で、純粋なPHPでファセット検索を含む全文検索を実装するつもりはなく、Etsyは Solr を使った