“Extreme Programming Explained”（邦訳「XPエクストリーム・プログラミング入門」）と“Test Driven Development: By Example”（邦訳「テスト駆動開発入門」）の著者であるKent Beck氏は、ソフトウェアにはゴルフのようにロングゲームとショートゲームがある、と話している。JUnitはロングゲームプロジェクトの一例だ。たくさんのユーザ、安定した収入（すべての関係者にとって$0は悲しいことだ）、そこにある重要目標はユーザのニーズの先を行くことだ。
JUnit Maxを始めてみて、ルールが変わったということが、だんだんわかってきました。キラークエスチョンはこうです。「どんな機能がお金を払ってくれる顧客を引き付けるのか？」明らかに、これは答えられない質問です。もしJUnit（もしくは、その他の無料パッケージ）がその機能を実装すれば、誰もMaxのその機能にはお金を払ってくれないでしょう。
JUnit Maxの成功は、自力での収入として定義することができます。つまり、お金を払ってくれるユーザが増えること、ユーザ当たりの収入が増えること、および、バイラル率を高くすることです。しかし、このように定義しても成功するための手段はわかりません。そのため、成功するチャンスを最大化するために、数多くの実験をして、実際の利用や導入からのフィードバックを取り入れる必要があるのです。
JUnit Maxはすべての内部エラーを中央サーバに報告している。こうすることで、Kent氏は問題が発生したことを知ることができる。このエラーログは2つの問題を発見するのに役立っているそうだ。1つは、簡単なテストを書くことで問題を再現させて修正できる問題。もう1つは、簡単に修正できるのだが、テストを書くのに数時間かかると見積もった問題だ。この場合、彼は修正だけをして、出荷していたそうだ。
Kent氏はこう続ける。
Maxを始めたとき、最初の1か月間は自動テストを一切やりませんでした。すべて手動でテストしていました。最初の数名の契約者を得てからは、立ち戻って、既存機能のためのテストを書きました。もう一度言いますが、このような順番にしたおかげで、単位時間当たりに実行できる有効な実験の数を最大化できたと思っています。コードをほとんど、あるいはまったく書かず、テストを書かないことで、ずっとすばやく立ち上げることができたのです（最初に書いたテストにはほぼ一週間かかった）。最初のコードに価値があることがわかってからは（友達の何人かがそれにお金を払ってくれるという意味で）、テストを書くことで、コードに自信を持ち、すばやく実験することができたのです。
自動テストを書くか否かを判断するには、いろいろな要因のバランスをとる必要があります。Maxでも、かなりたくさんのテストを書いています。もしテストを書くのに安っぽい考えができていれば、すべての機能を受け入れテストファーストで開発していたでしょう。特に、機能をどうやって実装すればよいかわからないときには、テストを書くことでよい考えが浮んできます。Maxを開発しているとき、テストを書くか否かという質問は、要するに、そのテストが単位時間当たりにより多くの有効な実験をするのに役立つかどうかでした。もし役に立つのであれば、私はテストを書きます。そうでなければ、不要だと判断します。私はMaxの収入を軌道に乗せるためのチャンスを最大化しようとしているのです。設計投資のための根拠についても同様に複雑なのですが、これはまた今後の話題としておきましょう。
Extreme Programming Installed（邦訳「XPエクストリーム・プログラミング導入編」）の著者、Ron Jeffries氏はこう答えている。「ショートゲームで正しい判断をするのに、私はあなたを信頼しています。他の3人についてもです。私の長い経験から、ショートゲームに対する判断には、影響にある種のニーカーブがあると思っています。過大な、また急激な信頼性を求めると、前進する能力は大幅に落ちてしまうのです。」
アジャイルソフトウェアコーチであるJohannes Link氏はこう言っている。「妥当な短期的/長期的判断のできる開発者のペアは見たことがあります。でも、そういうチームは見たことがありません。ましてや、そういう組織なんてね。」
一方、Michael O'Brien氏はこうコメントした。「すばらしい記事であり、正しい判断だと思います。コードを書いているときには、美しさと一貫性に夢中になってしまい、何のためにコードを書いているのか忘れてしまいがちです。私がテストを書いているのは、コードを書きやすくするためであり、そのコードが自分の考えていた通りに動くという自信を得るためです。もしテストを書いても、それを得るのに役に立たないのであれば、テストを省略するように言います。」
Olof Bjarnason氏は次のように考えている。「Kent氏の話に関係しているのは、フィードバックフローです。単位時間当たりのフローを高くすることに注力していれば、私たちは正しい方向に進むことができます。例えば、短期間にテストせずに機能追加することは、JUnit Maxプロジェクトの初期のフィードバックフローを最大化したのだと彼は言っているのです。最初のテストを書いたときには、テストを書くのが非常に難しくなっていました（一週間以上かかっている）。彼はそれを同時にうまくやってリリースすることにより、より高いフィードバックフローを得たのです。Kent氏にとって「レッド」状態のテストとは、最初の数少ないユーザとそのフィードバックだったのです。」
Guilherme Chapiewski氏は、ショートゲームだと思っていたら、実際にはそうではないことがあるという懸念を示している。Guilherme氏の場合、概念実証としてのテストをせずに、そのプロジェクトのコードを書くことを決めた。みんなが使い始めるとすぐに、修正できないバグがいくつか見つかるようになった。結局のところ、そのコードは腐っていて、テスト不可能だと彼は判断した。彼はそれを捨てしまい、スクラッチからもう一度やり直したそうだ。
Kent氏はたくさんのコメントに対してこう答えている。「プラクティスと原則を混同してしまうと問題になります。そして、テストすることは、よりすぐれた設計につながります。それこそが、私が約30の機能テストと約25のユニットテストをする理由です（バランスがおかしいのは、Eclipseアプリがテスト困難であるため）。私は新機能に関する作業のほぼすべてを、受け入れテストファーストでやります。これはサイクル時間を短縮するのに役立っています。」
こうした考えは、1人、2人を超えてうまくスケールするのだろうか？Kent Beck氏以外にも、うまくやれる判断力のある人はいるのだろうか？