Dan North 氏は先日の ”The Art of Misdirection” という記事で，機会費用のもたらす影響について持論を発表した。機会費用 (Opportunity Cost) は，別の選択肢の方が適切であるかも知れない特定の問題状況において，特定のソリューションを選択する行為によって生ずる。ソフトウェア技術者は日々の業務で意思決定に直面していることから，特にこのような機会費用を被りがちだ。
氏の意見によれば，ソフトウェア技術者はコストに関して楽観主義的に陥る危険性を常に持っている。それを立証するために氏は，次のようなテストを提案する。
ここで２つのテストをしてみましょう – あなたがソフトウェア開発で実践している，習慣あるいは技法をあげてください。お気に入りのプラクティスでもよいでしょう。できましたか？ ＯＫ，では第１問。それを実践している理由は何ですか？ どんなメリットがありますか？ いくつかあげられると思いますので，それらを書き留めてください。第２問。もしそれが実施できないとしたら，何で代用しますか？ いくつかあげて，それぞれ利点と欠点を書き留めてください。
氏は例として TDD (Test-Driven Development/テスト駆動開発) を取り上げる。氏はこれを "自分が知る限りでもっとも教義主義的なプラクティス" と表現している。
TDD によって発生する機会費用の原因として氏は，着実かつ確信的な修正作業，創発的デザイン，自動テスト，さらには生きたドキュメントとしてのテスト，などへの欲求をあげている。例えば金融取引アプリケーションの分野では，過剰なコストと時間の浪費を伴う TDD に比べて，複数の素案を試行する方が有効な可能性もある。創発的デザインに関しては，TDD はあたかも極大値を探し出すようなものであるため，最良のソリューションを見出すにはより根本的な再考が必要な場合もある。さらに生きたドキュメントとしてのテストの利用は，多くの不要なノイズをもたらす結果に終わるかも知れないのだ。
記事の結論として氏は，次のように勧めている。
何事も額面通りに受け取らず，すべての決定において妥協点を探しなさい。見出せるかどうかに関わらず，妥協点は存在します。それを見つける方法を習得さえすれば，マジックが使えるのです。
氏の意見に賛同するものもある。Gene Hughson 氏の意見では，
素晴らしい記事です。技術であれテクニックであれ，コストもメリットも十分に考えずに採用するのは，大惨事の原因にもなりかねません。
その一方で氏の意見に同意しない，あるいは反対する読者もいる。例えば Sam Weisen 氏はコメントで，氏の TDD に対する扱いは不当なものだ，と主張している。
筆者は TDD を誤解していて，無意味な攻撃を仕掛けているのではないでしょうか。要点を突いている部分もいくつかあるのかも知れませんが，長々とした説明のために不明確になっています。
Liz Keogh 氏は記事の内容を支持すると同時に，一部のアジャイル開発支持者たちは他の意見者に対してもっとオープンになるべきだ，という意見を持っている。
コメントを残している人たちの中には，"真のスコットランド人" 的詭弁の餌食となっている人が何人かいます。誰かのために役立っていないのなら，その人の行為は誤りである，という考え方です。それが私の，いくつかのアジャイルに関連するブログから得た感想です。TDD に関するものが多いのですが，スクラムでも事は同じです。タイムシートアプリケーションのロールアウトから，TDD を単純には適用できないような緊急を要する製品不具合のフィックスまで，数多くの状況が存在します。さらに TDD がプラクティスとして適切なものではあっても，最適ではないような場合も数多くあるはずです。
氏の主張はすべての人々から支持されている訳ではないが，特に TDD に関しては，新たな視点を得るための機会として認められるべきだろう。Justin 氏もその点を指摘している。
これまで盲点であった部分に対して，注意を喚起してくれたことに感謝します。この記事の行っているすべてのことが，これまでの快適な領域から踏み出して，あなたの考えを試してみるように促しているのです。成功を収めたチームの多くは，このようなメソッドをすべて寄せ集め，それらをまとめることで生産性を高めています。