そのラインの理由は根本的な緊張を示している。デビッド・ウィーラーが有名な言葉で言ったように、「コンピュータサイエンスのすべての問題は別の間接的なレベルで解決できる。ただし、間接的なものが多すぎる問題を除いて。」時間が経つにつれて、ますます巧妙な抽象が蓄積されていく。内面的に取り入れた抽象は見えなくなってしまう。それが私たちのやり方になって、他の人にどんなコストを強いているのか分からなくなる。すべての抽象は漏れがあるし、すべての抽象はメンテナンスプログラマーにとって障壁になる。これが、ブライアン・カーニハンが警告した問題につながる。「誰もがデバッグはプログラムを書くのの2倍難しいことを知っている。だから、書くときにできるだけ賢くなったら、どうやってデバッグするんだ？」結局、デバッグしなきゃいけないのは、あなたの抽象を知らないメンテナンスプログラマーだろう。Googleのアプローチから見える重要な知恵の一つは、業界全体が抽象に対して持つ傾向が有害だということ。特定の抽象が強力であっても、あまりにも多くなるとそれ自体が問題になる。だから、例えばGoは過剰な抽象を強く抑制するように設計されている。プロトバッファーは、言っている通りのことをする。意図されたシンプルな使い方をしていれば、うまく機能する。彼の不満は結局、「新しい抽象を生成するためにメタ操作を試みたけど、デザインがそれを許さなかった」ってことに集約される。それはアマチュアが書いたからではなく、ほとんどのプログラマーが無視できるほど賢いと思っているエンジニアリングの知恵を取り入れるために書かれているからだ。（過去の自分もそのプログラマーの一人だった。）技術は悪用されることもあるし、バカなことをする人もいるし、やりたいことができないこともある。もちろん。でも、KISSを守れば、うまくいく。シンプルに保てば保つほど、うまく機能する。これが、より良いエンジニアリングデザインを生み出すためのインセンティブだと思ってる。