ジョンは、銀行で働いていた頃の経験談を思い出した。彼らは、モーゲージの支払い金額を計算し、グラフを顧客に提示するためのクライアントサイド・アプリケーションを開発した。このアプリケーションは成功したが、後には、セールス・エージェントが携帯電話で使用できるモバイル・ウェブ・バージョンを要求した。初めの考えは、バックエンドのメインフレームに接続することだったが、メインフレームの開発者の不足により、代わりにモーゲージ計算オブジェクトをウェブ・サービスにラップすることにした。ウェブ・サービスはテストされ、うまく機能したが、時々、不合理的な結果を生じ、再現や診断が困難だった。問題は、シングルトン・オブジェクトが単一のリクエストにスコープされていないため、同時のリクエストが互いに干渉することを原因としていた。このシングルトン・オブジェクトは、オリジナルのクライアント・アプリケーションから残っていたもので、ユニークさを強制する必要がなかった。計算機は状態を保持しており、シングルトンではなかった方がよかった。修正は簡単で、シングルトン・パターンの使用を止め、各リクエストに計算機のインスタンスを提供することだった。この経験は、ソフトウェア開発におけるデザイン・パターンの誤った適用の例を示し、デザイン・パターンを適用する際の注意深さの重要性を強調している。この話は、単純な問題が複雑な原因を持つことがあり、コードとデザインの注意深いレビューが簡単な解決策に導くことを示している。