2010年にSteve Freeman氏は，バッドコード(Bad Code)は技術的負債ではなく，ヘッジのない(unhedged)コールオプションである，とするブログ記事を発表した。記事の中で氏は，Chris Matts氏がバッドコードを表現するために，"アンヘッジド・コールオプション"というメタファを使うアイデアを思い付いた経緯を説明している。
汚い(テストのない)コードは，行動に対する予測不能性という意味で，負債よりもコールオプションの方がモデルとして適切です。クリーンアップされていない機能が手に入ったら，まずはそのメリットを享受して，とりあえずの手当てをしておきます。ここでもし，そのコードを二度と見ることがなければ，私は先走りしたことになります。振り返ってみれば，コードのクリーンアップに費やした時間は無駄だった，ということになるでしょう。
一方で，根本的に新しい機能を課題として与えられた場合，このようなクイックフィックスによる対処は，大変難しい作業になります。私の見た例では，別のプラットフォームへの移植が必要な大手クライアントや，新たなレポートを要する新しい規制要件，といったものがありました。同じような問題は，解釈上の間違いを期限までに修正しなければならない場合や，チームメンバが完全に職を離れてしまう上に，コードの理解に必要な暗黙知を誰も引き継いでいない場合などにも見られます。市場が私の予想とはまったく違う方向に動いてしまって，私のオプションがコールされた，ということです。
このブログ記事が最近になって，RedditとHacker Newsで激しく議論されている。反応の中には，次のようなものがある。
メタファに使う言葉を選ぶのに，深読みすることはありません。負債といっても金融や経済など，金銭の話ではないのですから。
あまり一般的でないメタファを選択すると，事態が改善されなくなります。バッドコードの何がいけないのかを正確なメタファで説明することに時間を費やすよりも，バッドコードを書かないための行動が必要なのです。バッドコードがよくないことは，みんな知っています。メタファを換えてみたところで，何も変わりません。
[技術的負債という用語は]拙速なソフトウェア開発プロセスの性質と結果について，誤った認識をいくつも生み出しています。そして，特にこれをやっているのがビジネス指向の人たち，つまり，与えられたタスクへのリソース配分を行っている，まさにそのグループの人たちなのです。
技術的負債はよいことなのかも知れません。製品を予定どおりにリリースできるかも知れませんし，いわゆる技術的負債の解消に取り組んでいる間に，利益を回収できるかも知れないからです。多くの面で，金融の負債と同じです。
現実の負債は簡単に把握できます。気が確かな人ならば，収入の1000%に相当する融資を受けて，会社の予算の大部分をその利息に食われてしまうようなまねはしません。ところが技術的負債では，まったく同じことが至る所で起きているのです。
アナロジとして不完全であることは確かです。コードの拡張やメンテナンスが必要なければ，利息を払うこともないのですから。Iこのアナロジが有効なのは，問題のコードベースが開発中である場合に限られます。ですが，私たちがこの比喩を使うのは，そのような状況なのです。あなたの挙げたケースには，ネイキッドコール(Naked Call)というアナロジがぴったりです。
“保険の販売”という呼び方は極めて妥当です。“オプション”というと何も思い浮かびませんが，保険の販売という表現は，当面の小さなプラスと，将来的に潜む大きなマイナスをうまく捉えています。
私が携わっているプロジェクトはマネージャも認識しているほど酷いものなのですが，その状況を上級幹部にいくら説明しても(増員が必要だとか，リファクタの時間が必要だとか)，彼らは聞こうともしてくれません。
InfoQでは，バッドコードと“コードの臭い(code smells)”に対するメタファの使用，低品質なコードのトレードオフとコスト，コード品質に対する責任などについて，SteveとChrisにインタビューした。
InfoQ: 2010年にこのブログ記事を書こうと思った理由は何ですか？
Steve: それより少し前からChrisが，このメタファを使っていたのです。私はそれを聞いて，この問題に新たな視点を取り入れるものだと思いました。私が当時携わっていた金融機関に関しては，特に気の利いたアイデアだと思ったのです。Chris自身がそれについて書くのは，彼が面倒に思うだろうと思っていましたから，代わりに私が書きました。
InfoQ: ジョークに過ぎなかった過去の記事がなぜ突然，注目されるようになったのでしょう？
Chris: メタファは簡単に言えば，共通の意味を作り出すための手段です。開発者が技術的負債というメタファを使うのは，ビジネスの投資家やマネージャに行動を起こしてもらいたいからです。負債でも，オプションでもいいでしょう。どちらもツールなのです。新しいツールに人々が興奮するのはなぜでしょう？
Steve: 分かりません。私には，そういったことはありませんでした。私にとって印象的だったのは，頂いたコメントのいくつかがとても真剣だったことです。新しいメタファは，状況を考えるための手段なのです。
InfoQ: 技術的負債の意味は，多くの人が知っています。アンヘッジド・コールオプションという，新しいメタファを考えついたのはなぜでしょう？
Steve: さまざまな定義を聞いていますが，Ward Cunningham氏(オリジナル)の定義では，ハックコードというよりも，部分的に実装された機能という意味だと，個人的には解釈しています。Chrisの独自な点は，特定のサークル，例えば金融市場においては，負債は望ましいものだということです。アンヘッジド・オプションは人々の注意を促すという点で，トレードのひとつのツールなのです。
多くの人たちが見落としていると思うのですが，私は，コードベースがオプションのポートフォリオで，コーディング上の個々の選択がオプションの販売だ，と説明したかったのです。状況が変われば，これらオプションのいくつかがコールされます。ほとんどの場合はそれが限界費用ですが，大きな変化があって，非常に高価なものになることもあるのです。
Chris: Steveの定義は妥当だと思います。開発チームとしてのあなたは，販売されたコールオプション(技術的負債)を管理します。オプションの返済費用は，そのコンポーネントを変更する可能性の高さに依存しています。ここでは，Todd Littleの“トルネードマップ(Tornado Maps)”の概念が役に立ちます。プロダクトオーナが，彼らの行うであろう作業の長期的な予測を立てます。チームはその予測を使って，技術的負債としてのトルネードが降り立つと思われる場所を目指していくのです。
InfoQ: 負債は予測や管理が可能なので，技術的負債というのはメタファとしてあまり適切ではない，という話がありましたが，アンヘッジド・コールオプションについてはどうなのでしょう？思惑や，バッドコードで高いリスクを取るような行為を示唆してはいないでしょうか？
Steve: “クレジットカード”の技術的負債が問題になるのは，それが低品質の非直線性を反映できていない点です。バッドコードに二度と触れることがなければ，それが問題になることもありません。その一方で，状況のわずかな変化から，壊滅的な被害を被る可能性もあります。たとえリスクを覚悟していたとしても，ヘッジしないことの危険さは，金融市場の誰もが知っていることなのです。
デリバティブの暗黒面は，経済システム全体に災いをもたらしました。ですが，よい点もあります。オプションは賢明に使用さえすれば，有効なリスクマネジメントツールです。紀元前4000年頃から，シュメールに農産物先物の記録があるのは，恐らくはそのためです。
コード品質のトレードオフを分析する，もっとよい方法があるといいと思います。それを実際に行えるようなツールを思い付かないのですが，Chrisが絶えず口にしているので，オプションという考え方に関心を持つようになったのです。
InfoQ: 2010年以降，状況は変わったと思われますか？進む方向が変わったのでしょうか，それとも相変わらず，バッドコードが問題を引き起こしているのでしょうか？
Steve: 改善されたものもあります。例えば，それまで他のチームのものだった継続的ビルドや自動テストに，開発者も関与することが多くなりました。バッドコードの持つ意味について合意ができたとしても，生きている間に，それが消えてなくなるとは思えません。
Chris: 議論が進展しているのかどうか，あまり確信は持てていません。ソフトウェアクラフトマンシップのコミュニティは，“美しいコード”というコンセプトに向かっています。ですが，美しいコードがいつどこで必要なのか，多少美しくなくても構わないのはどこなのか，そういったことを本当に話している人はいません。コードの品質は開発者だけではなく，プロダクトオーナにも同じように責任があります。すべての場所で美しいコードを求めるのは，もうけ話の投資先を知らないビジネス投資家のような状況に結び付きます。開発者のコミュニティがビジネス投資家の視点を真剣に取り入れるまでは，汚いコードをあらゆる場所で見続けることになるでしょうね。