John recalled a story from his past experience working at a bank where they developed a client-side application to help sales agents calculate mortgage payments and display graphs to customers. The application was successful, but later on, the agents requested a mobile web version that they could use on their phones. The initial thought was to connect it to the backend mainframe, but due to a lack of mainframe developers, they decided to wrap the mortgage calculation objects in a web service instead. The web service was tested and worked well, but sometimes it produced absurd results, which were difficult to reproduce and diagnose. The issue was eventually found to be caused by a singleton object that was not scoped to a single request, allowing simultaneous requests to interfere with each other. The singleton object was a leftover from the original client application, where it was not necessary to enforce uniqueness. The calculator held state and probably should not have been a singleton in the first place. The fix was simple, which was to stop using the singleton pattern and ensure every request got its own instance of the calculator. This experience serves as an example of the misapplication of patterns, highlighting the importance of careful consideration when applying design patterns to software development. The story demonstrates how a seemingly simple issue can have a complex cause, and how a careful review of the code and design can lead to a straightforward solution.