退屈なテクノロジーを選ぼう (2015)

おそらく私のキャリアで起こった最も素晴らしいことは、Kellanが私の責任者になったことでした。私はKellanの技術的意思決定が成果を上げ始めるのを見るまで、しばらく留まりました。このことから多くのことを学びましたが、その結果としても多くのことを学びました。Kellanが技術選択を完璧に成功させてくれなかったら、Data Driven Products Now!を書いたエンジニアになる自由はなかったでしょう。いつも通り、感動的でした。 Etsyを辞めてから1年、私はテクノロジーへの関心を取り戻しました。そして私の考えは、それらを首尾一貫して書き留めることができるレベルまで結晶化しました。以下は、Kellanのゲシュタルトの蒸留であり、彼をわずかにしか恐れさせないことを願っています。 退屈さを受け入れよう。 すべての会社には、およそ3つのイノベーション・トークンがあるとしましょう。これらをどのように使っても構いませんが、供給はしばらくの間固定されています。ある程度の安定性と成熟度を達成すると、もう少し増えるかもしれませんが、一般的な傾向は、自分の財布の中身を過大評価することです。明らかにこのモデルは近似ですが、役立つと思います。 あなたのウェブサイトをNodeJSで書くことにした場合、あなたはイノベーション・トークンを1つ使いました。MongoDBを使うことにした場合、あなたはイノベーション・トークンを1つ使いました。1年以下の歴史しかないサービスディスカバリ技術を使うことにした場合、あなたはイノベーション・トークンを1つ使いました。自分でデータベースを書く場合、ああ、大変なことになります。 それらの選択肢は、あなたがJavaScriptコンサルタントやデータベース会社であれば、賢明かもしれません。しかし、あなたはそうではないでしょう。あなたは、少なくとも表向きは、グローバルコマースを再考したり、ウェブ上の決済を再発明したり、その他の十分に壮大な使命を追求している会社で働いているのでしょう。その文脈で、限られた注意力をSSHを革新することに費やすことは、失敗する素晴らしい方法です。あるいは、せいぜい成功を遅らせるだけです[1]。 何が退屈と見なされるか？それは少しトリッキーです。「退屈」は「悪い」と混同されるべきではありません。世の中には、退屈で悪い技術も存在します[2]。それらは決して使うべきではありません。しかし、退屈で良い、あるいは少なくとも十分良い、多くの技術の選択肢があります。 MySQLは退屈です。Postgresは退屈です。PHPは退屈です。Pythonは退屈です。Memcachedは退屈です。Squidは退屈です。Cronは退屈です。 退屈さ（このように制約されたもの）の良い点は、これらの機能の能力がよく理解されていることです。しかし、より重要なのは、それらの失敗モードがよく理解されていることです。 私をよく知っている人は誰でも、私がドン・ラムズフェルドの亡霊を呼び出すのは、圧倒的な倦怠感からであることを理解するでしょうが、そうしなければなりません。はっきり言っておきますが、あの男はクソです。技術を選択する際、あなたは既知の未知数と未知の未知数の両方を持っています[3]。既知の未知数とは、「このデータベースがCPU使用率100%になったときに何が起こるか分からない」といったことです。未知の未知数とは、「統計情報を書き出すことがGCの一時停止を引き起こすとは思いもしなかった」といったことです。どちらのセットも、数十年前から存在する技術であっても、通常は空ではありません。しかし、ピカピカの新しい技術の場合、未知の未知数の大きさは著しく大きく、これは重要です。 グローバルに最適化しよう。 私は、退屈な技術を支持するというバイアスが良いことであると公言して疑いませんが、それは考慮されるべき唯一の要因ではありません。技術選択は孤立して起こるものではありません。それらはあなたのチーム全体、組織全体、そしてあなたの選択の総体から生まれるシステムに触れるスコープを持っています。 会社に技術を追加することにはコストが伴います。抽象的な声明としては明白です。もし私たちがすでにRubyを使っているなら、Pythonを混合に追加するのは、結果として生じる複雑さがPythonの限界的な有用性を上回るため、賢明ではないように思えます。しかし、なぜかPythonとScala、あるいはMySQLとRedisについて話すとき、人々は我を忘れ、すべての制約を捨て、「仕事に最適なツールを使う」と熱狂し始めます。 あなたの役割は、ビジネスの問題をソフトウェアの選択を含むソリューション空間にマッピングすることです。もしソフトウェアの選択が本当に負担なしであれば、あなたは確かにあなたの問題の寄せ集めのために、局所的に最高のツールの山を選ぶことができるでしょう。 クレイジー Sketchで作成 問題 技術的解決策 選択肢が安価な世界で技術を選択する方法：「仕事に最適なツールを選ぶ」 しかし、もちろん、負担は存在します。私たちはその負担を「オペレーション」と呼び、より少ない程度で「認知的オーバーヘッド」と呼びます。あなたはそれを監視しなければなりません。あなたは単体テストを考え出す必要があります。あなたはそれにハックするために、それについての最初のことを知る必要があります。あなたはinitスクリプトが必要です。私はここで何日でも続けることができますが、これらすべてが急速に積み重なります。 健全 Sketchで作成 問題 技術的解決策 オペレーションが深刻な懸念事項である世界（つまり、「現実」）で技術を選択する方法。 「仕事に最適なツール」という考え方の問題は、「最適」と「仕事」という言葉を近視眼的に見ていることです。あなたの仕事は、神に誓って、会社を事業として継続させることです。そして「最適な」ツールとは、できるだけ多くの問題に対して「最悪ではない」位置を占めるものです。信頼性の高いシステムを維持するための長期的なコストは、それを構築する際に遭遇するどんな不便よりも、常にそれを上回ります。成熟した生産的な開発者はこれを理解しています。 新しい技術を、時には選ぼう。 この推論を極端に推し進めると、Javaを選び、そしてそれ以外の何も使わずにウェブサイトを実装しようとすることになります。それは狂気の沙汰でしょう。 ツールボックスに何かを追加する手段が必要です。重要な最初のステップは、これがプロセスであり、会話であることを認識することです。新しい技術は最終的に会社全体に影響を与えるため、技術の追加は会社全体の可視性を必要とする決定です。 あなたの組織の特定の問題が会話を強制するかもしれませんが、あるいは開発者が誰とも話さずに新しいデータベースやキューを追加することを容易にするかもしれません。いずれにせよ、私たちは皆このことについて話し合う必要があるという文化的な期待を設定する必要があります。 ここで私が推奨する最も価値のある演習の1つは、新しいものを何も追加せずに、現在の問題をどのように解決するかを検討することです。 まず、この質問を提示することで、「問題」が誰かが本当にその技術を使いたいと思っている状況を検出するはずです。もしそうなら、あなたはすぐに中止すべきです。私はちょうどこのグラフデータベースについてのウェビナーを見ました、私たちはそれを試してみるべきです。 少数の技術選択がどれだけ遠くまで行けるかは驚くべきことです。この質問に対する答えは、実際には「できない」ということはほとんどなく、通常は「まあ、できるだろうけど、難しすぎるだろう」というスペクトルのどこかにあります[4]。もしあなたが、今持っているもので目標を達成できないと思うなら、あなたは創造性が足りないだけかもしれません。 現在のスタックの何が、問題を実行不可能に高価で困難にしているのかを正確に書き出すことは役立ちます。これは前の演習に関連していますが、微妙に異なります。 新しい技術の選択は、純粋に追加的なもの（例：「まだキャッシングがないので、Memcachedを追加しよう」）かもしれません。しかし、それらはあなたがすでに使用しているものをオーバーラップしたり、置き換えたりすることもあります。もしそうなら、あなたは古い機能を新しいシステムに移行するための明確な期待を設定すべきです。 ポリシーは通常、「移行にコミットする」というもので、提案されたタイムラインが必要です。このステップの意図は、残骸を管理可能なレベルに保ち、局所的に最適なソリューションの拡散を避けることです。 このプロセスは daunting ではなく、大した手間でもありません。宿題として記入する数個の質問と、それについて話し合うための会議です。 私は、新しい技術（またはあなたのインフラストラクチャ上に作成される新しいサービス）がこの試練を無傷で通過できるなら、追加しても問題ないと思います。 ただ出荷しよう。 ポリグロットプログラミングは、開発者が自分のツールを完全に自由に選択できるようにすることで、問題解決においてより効果的になるという約束とともに販売されています。これはナイーブな考え方です。