We continue on a series of new patterns and anti-patterns with “the worst that can happen.” This pattern uses fear and hyperbole to help us tighten up a design. We imagine what can go wrong and use that as a guide for applying fixes, hooks, and exceptions. Thus, this pattern is more a process than a pattern per se. However, it is an important step we can take to validate and strengthen our solution.
The Worst That Can Happen Pattern Defined
The pattern is applied by reviewing an architectural design or component with the mindset of the worst that can happen. Thus, we force ourselves to think outside the box and play our way through difficult scenarios. Disaster recovery planning often uses this pattern. First, we look at the worst possible scenarios and the related costs. Then we assess whether we need to build a circumvention mechanism or risk the scenario. That last point is essential in our review. Of course, we can decide to ignore handling some situations because of a low cost, risk, or likelihood. For example, the end of the world could happen. However, we do not feel like that is something we want to handle among our exceptions.
Applying The Pattern
Applying this pattern is a challenge as it searches for variants from the “happy path” in our solution. First, we examine inputs and outputs with an eye toward how those can “break” or be missing. Then, we plan a strategy for handling those problems. The goal is to ensure we understand the risks and costs associated with our solution. Of course, there is always an option to push some of these issues into a backlog or a technical debt pile. However, that at least makes them known quantities.
