Part 1 of 2
Devesh Korde
April 27, 2026
I learned design patterns from a textbook in university.
The textbook showed a problem. A Singleton pattern. A Factory pattern. An Observer pattern. Each one solved a specific, abstract problem. The code was clean. Decoupled. Elegant.
Then I got to my first job and realized nobody was asking about abstract problems.
They were asking: why is this component so hard to test? Why do I have to change this file when I only touched that file? Why does this dependency flow hidden and cause crashes nobody can predict?
Design patterns were supposed to solve these problems. Sometimes they did. Often they made them worse.
Here is the uncomfortable truth: most design patterns are solutions to problems that do not exist in your codebase. You are solving for elegance. Production needs clarity.
A design pattern is taught like this:
"You have a problem. Components need to communicate without being tightly coupled. Solution: Observer pattern. You have observers. You have observables. When state changes, observers are notified. Elegant. Decoupled."
In a textbook, this is correct. It solves the problem it is supposed to solve.
But in production, you have a different problem:
"We have 50 components. A state change in component A triggers an observer in component B which triggers a side effect in component C. When component B changes and component C breaks, I have to trace through observer registrations that happen in constructors, setup methods, and lifecycle hooks spread across 10 files to understand what is happening."
The Observer pattern is now a liability. Not because it is a bad pattern. Because the problem it solved is not your actual problem.
Your actual problem is: I do not understand what happens when state changes. The pattern made that problem worse, not better.
Design patterns are templates for solving abstract problems in abstract ways.
They prioritize:
What they do not prioritize:
This is fine in textbooks. It is a problem in production.
A Factory pattern decouples object creation. This is elegant. But the developer reading the code now has to follow the abstraction to understand what object is actually being created. They have to read the Factory implementation. Then read the concrete implementations. Then understand the polymorphism.
A simple new UserRepository() does the same thing with no indirection. It is less elegant, but it is clear.
The question is: is the elegance worth the cost?
In a small codebase with one developer, it is not. In a large codebase where object creation is truly a pain point, it might be.
Most of the time, we apply patterns without answering this question. We apply them because they are elegant. Because they are taught. Because they look good in code reviews.s
A design pattern is only useful if you apply it consistently.
A single Singleton is not too bad. You have one globally accessible instance. You know where it is. You can find it.
But Singletons breed. You have a logger Singleton. A config Singleton. A database connection Singleton. A cache Singleton. A service Singleton.
Now you have hidden global state everywhere. Your unit tests are failing because Singletons from a previous test are still alive. Your code is hard to trace because state changes invisibly from anywhere.
The pattern that looked elegant when you applied it to one problem became a nightmare when you applied it to five problems.
This is the consistency trap. Once you pick a pattern, you have to apply it everywhere to avoid cognitive dissonance. But applying it everywhere creates problems that applying it to one problem did not.
A strategy of "use Singletons for global state" works fine with one Singleton. It breaks when you have ten.
The textbook never explains this because textbooks show one pattern in isolation. Production has ten patterns interacting.
I watched a developer spend two days building a Decorator pattern for a logging system.
The pattern was elegant. It let you add logging to any method without modifying the method. Just wrap it. The wrapper logs. The decorator chain is clean.
In the end, the Decorator implementation was 300 lines. The logging it was adding was 50 lines.
A simple if statement would have done the same thing in 10 lines.
The pattern made the code harder to understand. It added indirection. It made the logging harder to test because you had to understand the Decorator chain.
The problem was not real enough to justify the pattern. The problem was "we want logging in this function." The solution was "add a log statement." The pattern was cargo cult.
But it looked good. It was elegant. It was extensible for future logging needs that would probably never happen.
That extensibility cost 300 lines of code for 50 lines of functionality.
Design patterns prioritize extensibility. They solve for future use cases.
"This Factory pattern lets us easily add new implementations later without changing the client code."
This is true. It also means:
The textbook says: "Good design should be extensible."
Production says: "Code that is easy to understand and change is more important than code that is hard to change because it is flexible for changes we have not thought of yet."
Most of the time, the future is not what you predicted. You will change the code anyway. The extensibility you built for will be wrong.
You could have written simple code. You could have changed it when the requirements changed. But instead you wrote flexible code for a future that did not arrive, and the flexibility became a burden.
The developers who understand design patterns well are not the ones who apply them everywhere.
They are the ones who:
Most design patterns are applied to problems that do not exist.
A junior developer learns patterns. They love patterns. They see elegant solutions to abstract problems. They apply them everywhere. They think they are being a good engineer.
But they are not solving real problems. They are solving the textbook problems.
A senior developer knows the patterns. But they also know that the patterns are tools, not laws. They know that most code does not need the elegance that patterns provide. They know that simplicity is the enemy of bugs.
The developers who struggle the most with production code are often the ones who learned patterns well and never questioned them.
The developers who produce the best code are the ones who ask: "Is this problem real enough? Is the pain significant enough? Is the pattern worth the cost?"
And often the answer is no.
