The Art of Saying No: The Harsh Truth About Design Patterns

Imagine you’re knees-deep in a project deadline, navigating through so many lines of messy code that resemble a spaghetti factory explosion. You’ve probably been there: tempted to implement a clever design pattern you recently learned about, hoping it will be the magic bullet for all your coding woes. But here’s a reality check: “most developers either misuse or don’t know what they are doing with design patterns”. It’s not because they’re bad at coding, but they’ve fallen into the trap I like to call Pattern worshiping.

If you’re the type of developer who finds themselves forcing a Pattern into a project that didn’t need one, you’re not alone, and this page is for you. By the end, you’ll not only understand how to stop turning your architecture into a ‘look what I have learned in school’ museum, but you’ll discover how to save valuable time, reduce the introduction of bugs, and improve code review outcomes by choosing solutions that truly solve your problem.

The myth of the “Perfect” Design Pattern

Let me give you a quick reality check: THERE IS NO UNIVERSAL BEST PATTERN.

The right pattern in one project could be the wrong pattern in another. Yet, including myself at times, we developers often pick a pattern simply because a tutorial made it look sexy. This leads to bizarre overengineering, such as creating a simple object using a Builder, Factory, and Prototype pattern simply because the textbook made it look cool. Consider this: a startup once spent a month implementing an intricate Builder-Factory architecture, only to realize that it could be refactored in a single day using straightforward functions. This real-world example illustrates the potential pitfall of blindly applying complex patterns where simplicity would suffice.

A pattern should never be your objective; it should only make your solution simpler, not more complex.

Harsh Truth #1 - Patterns Are Tools, Not Goals

Hammers are a great tool when you have a bunch of nails, but they are awful when you try to fix a leaky pipe.

Design patterns are similar; they are tools that can be great for the right task. If you start a project and think, “I want to use a singleton pattern,” You are not addressing the underlying problem, but rather your desires

A code base can quickly become overcomplicated when we use patterns that do not fit the task. Sometimes, a simple if statement will do a better job.

Before you begin implementing a new pattern, ask yourself these three questions:

1. Does using a strategy pattern here reduce complexity, or are we simply rearranging it?
2. Will the code be easier to maintain after implementing the pattern?
3. Will future developers understand and appreciate the added complexity?

Harsh Truth #2 - Ignoring Constraints will lead to wrong choices

For most of us, we are not writing code on supercomputers with unlimited memory, crazy performance, and super high concurrency. We work in a world where we are restricted by boundaries and constraints. When selecting a pattern, we must consider all our constraints, including the team’s experience, deadlines, business requirements, and performance. To help ensure these constraints are at the forefront of consideration, here is a checklist of typical project limitations you should evaluate:

• Memory availability
• Latency requirements
• Team skill levels
• Project deadlines
• Business needs
• Performance targets
• Scalability demands

If we ignore our constraint, we’ll end up with mismatched solutions. The right pattern is the one that fits within our boundaries and doesn’t violate our constraints.

Harsh Truth #3 - You’re Probably Copying, Not Designing

This one might be a bit awkward, but many developers don’t apply patterns; they simply copy them. They find some pattern, copy it into their codebase, change some class name, and call it a solid architecture. The problem with this is that textbook examples all live in a perfect world where requirements never change and performance is someone else’s problem. To truly embrace the creative process of design, ask yourself: ‘Which parts of this pattern can we safely drop or modify while still achieving our goals?’ This mindset encourages adaptation rather than blind replication, allowing for solutions that are tailored to the specific challenges of your project.

The code we write will not live in that perfect world. This means we need to adapt and modify the pattern to make it fit within our domain. We need to tweak the pattern to ensure it operates within our boundaries and does not cross any constraints. Blindly copying a perfect example will fall apart when reality comes knocking.

Patterns don’t make you smart; good choices do

A well-chosen pattern can make your code elegant and maintainable, but the wrong choice leads to unnecessary complexity. Choosing a pattern should always serve your problem, not overshadow it.

The harsh truth is: just knowing design patterns does not make you a good developer, but knowing when not to use them will bring you pretty close to being one.

Instead of defaulting to whatever is trending, we can follow a simple framework. Next time you’re faced with a problem, follow these five guidelines:

1. Define the problem clearly
2. Identify constraints
3. List candidate patterns
4. Evaluate trade-offs
5. prototype and test

So next time, remember: your real goal isn’t to use fancy patterns, but to solve the problem in front of you as directly as possible.