Chris Matts氏の次のような質問から議論は始まった。
私が過去3年間で利用した最も強力なテクニックの1つは、latent code patterns (lcp)（潜在的なコードパターン）です。私がやってきたプロジェクトでは、すべての機能を設定可能にしてあります。これは、修正や機能追加をするのに他の機能のテストを待つ必要はない、ということを意味しています。私たちはすばやく効率よくリグレッションテストをすることに注力していました。頻繁にリリースしていたのにも関わらず、ずっと1つのブランチだけだったので、コードのマージという問題もありませんでした。
latent code patternsを使っている人はいますか？優れた新しいアイデアというものは、実際に問題を抱えていた人から生まれるものです。そのため、他の人がどうやっているのか知りたいです。
lcpがもたらすもう1つの問題は、テストにおけるWIP limit（仕掛り制限）です。どう思いますか？
基本的にChris氏が報告しているのは、彼のチームは機能を自由にオン/オフできたということだ。そのおかげで、ある機能がまだ作業中だとしても、その機能をオフにできるのでリリースに支障は出ない。 Chris氏はその後、あらゆる設計判断の背景にある疑問を共有することで、このアプローチの背景にある考え方について語った。
この（設計）アプローチはコミットメントを生み出すか？
Chris氏と同じチームにいたDavid Roussel氏は、チームがこのアプローチを正確にどう実施していたのか、その技術的詳細を明らかにした。そして、他の人がこうした解決策をどのように実施していたのか、その方法についてまとめた。
これにはたくさんの方法があると思います。しかし、最終時点でリリースを再度優先順位付けできる必要があること、そして、ブランチなしで簡単にそれができることに気づいたのは、大きな進歩でした。それ以外は詳細ですが、興味深いところです。
これ以外で、どのように解決しているのか？これまでのところ、以下が挙がっています。
- 依存性の注入 (dependency injection)、ビルド時に変更する依存性を利用
- 依存性の注入、コンフィグに基づいて上書きする依存性を利用
- 単純なコンフィグやif文
- 機能毎のブランチ
- コマンドドキュメント、コマンドパターン
- データベースに基づくコマンド設定（もっとよい名前が必要）
またJoshua Kerievsky氏は、このリストに次のような解決策を追加した。
David、私たちはまだ作業中のコマンドを出荷することもあります。これはユーザの目に触れることはありませんが、URL経由で実行可能です。Latent Commands（潜在的なコマンド）とでも言うべきものでしょうか？
あなたのリストに含まれているかわかりませんが、メニュー項目を非表示にするという単純なテクニックもありますね。
こうした設計テクニック（あるいは、もし望むならアーキテクチャ）は新しいものではない。実際のところ、これはアジャイルソフトウェア開発よりも古く、多くはオプジェクト指向やパターンコミュニティに由来している。しかし、これが満たしている要件、すなわち、Chris氏の質問である
この（設計）アプローチはコミットメントを生み出すか？
は、新しいものだ。