http://martinfowler.com/bliki/FaultyTechniqueDichotomy.html

私の人生で最もシビれるのは、ソフトウェア開発技術を集め、改善していくことである。 そのため、良かれ悪かれ、実際に使用している技術の話を聞くことに多くの時間を割くようにしている。

そのためか、欠陥技術の話をしばしば耳にする。 「FITはつかえねー」 「ストアドプロシージャにロジックは入れてはならない」 「TDDを使うとカオス状態に陥るだけ」等々。 欠陥技術のレポートを読むときに重要なのは、 技術それ自体が欠陥なのか、使い方が問題なのかをきちんと判断することである。

例をいくつか挙げてみよう。 友達がストアドプロシージャ最悪と言っていたが、 それはバージョンコントロールを使ってないからだった （その代わりに、GetCust01, GetCust02, GetCust02B と名前を付けて…略）。 それはストアドプロシージャの問題じゃあない。 ちゃんと使ってないのが問題なのだ。 同様に、TDDだと設計がおかしくなると言ってた連中に話を聞いてみたら、 リ フ ァ ク タ リ ン グ を や っ て な か っ た。 リファクタリングはTDDのコアだっつの。

もちろん、やりすぎてしまうと逆効果だ。 いつも言ってるだろう。「欠陥のない方法論などない」と。 だが、そういう欠陥は方法論を見れば事前に分かるものだ （失敗が何なのか分かっていればという前提だが）。 つまり、方法論についていけなかっただけであって、方法論自体が悪かったんじゃない。 こういう話は、自己適応型のアジャイル方法論の場合、もっと複雑になる。

というわけで、だ。欠陥技術だという話を聞いたら、 ちょっとその話詳しく聞かせて下さいと言うべし。

  • 問題あるのは技術自体だったのか、なにか見逃してなかったか。他の技術が影響を及ぼしていなかったか（バージョンコントロールとストアドプロシージャとは別物だが、バージョンコントロールなしでストアドプロシージャを使うのはしんどい。ツールには相性というものがある）。
  • その技術、本当に適してたわけ？（テストしてないのに、ドデカいリファクタリングやってない？）ソフトウェア開発は人間の営みなのだ。文化や嗜好の相違で、ツールが合わないことだってある。
  • 重大な何かを見逃してたとか？
  • 現実離れした何かがやってくるとかなんとか思ってなかった？ Steve McConnellがこのことをカーゴカルトソフトウェアエンジニアリング(PDF)と呼んでいる。

ここで気になるのは、その技術が脆いかどうかだ。 正しく使うのが難して、問題のあるアプリケーションが出来てしまうような技術は、脆いと言える。 使い方の難しさは、その技術自身の制限となってしまい、その技術が使える局面を狭めてしまう。

この問題に対するシンプルな答えはない。 成功を計測できないのと同じで、 技術がきちんと適用されているかなんて測りようがない。 ただし、重要なのは、欠陥技術の話を聞いたときには、 二分法を忘れるなってことだ。