John se souvint d'une histoire de son expérience passée travaillant dans une banque où ils ont développé une application côté client pour aider les agents de vente à calculer les paiements hypothécaires et à afficher des graphiques aux clients. L'application a été un succès, mais plus tard, les agents ont demandé une version web mobile qu'ils pouvaient utiliser sur leurs téléphones. La première pensée était de la connecter au système principal de la banque, mais en raison d'une pénurie de développeurs de système principal, ils ont décidé d'envelopper les objets de calcul des paiements hypothécaires dans un service web à la place. Le service web a été testé et fonctionnait bien, mais parfois il produisait des résultats absurdes, qui étaient difficiles à reproduire et à diagnostiquer. Le problème a finalement été trouvé être causé par un objet singleton qui n'était pas étendu à une seule requête, permettant aux requêtes simultanées d'interférer les unes avec les autres. L'objet singleton était un vestige de l'application client originale, où il n'était pas nécessaire d'imposer l'unicité. Le calculateur conservait un état et aurait probablement dû ne pas être un singleton dès le départ. La solution était simple, qui consistait à cesser d'utiliser le modèle de singleton et à s'assurer que chaque requête obtenait sa propre instance du calculateur. Cette expérience sert d'exemple de mauvaise application des modèles, mettant en évidence l'importance d'une considération soigneuse lors de l'application de modèles de conception à la développement de logiciels. L'histoire démontre comment un problème apparemment simple peut avoir une cause complexe, et comment une révision soigneuse du code et de la conception peut conduire à une solution simple.