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.


This pattern can create rabbit holes to go down and get lost.  There is a cost-benefit to every potential problem, which must be considered.  When we fail to evaluate costs properly, we can end up with a never-ending list of special cases to address.  The end-of-the-world example is a way to view these.  When it looks like the cost of the worst that can happen is too much to overcome, then hope for the best.

Rob Broadhead

Rob is a founder of, and frequent contributor to, Develpreneur. This includes the Building Better Developers podcast. He is also a lifetime learner as a developer, designer, and manager of software solutions. Rob is the founder of RB Consulting and has managed to author a book about his family experiences and a few about becoming a better developer. In his free time, he stays busy raising five children (although they have grown into adults). When he has a chance to breathe, he is on the ice playing hockey to relax or working on his ballroom dance skills.

Leave a Reply