Why Patterns Suck

It was surprising for me to hear people saying "Patterns suck", I wanted to know why people hate these precious guidelines to save us to reinvent the wheel and let us to use it.

After few days I had to work with some arrogant people who known to be pattern-lovers. Having a lot of technical knowledge, they used to remember the names of patterns and writers on finger tips. You can talk to them for not just hours but for days. In the first place I admired them and found myself among great people.

Then I found something strange, besides all their technicalities they had very few success stories so what was the problem?

I had started observing the causes of their failure. In the mean time I had to design an architecture for a coming enterprise project. I started scaffolding by enhancing and optimizing my legacy libraries and framework with my team. I asked those people to review my approach to let me become foolproof.

Geeks love technicalities so I got a prompt response and they started highlighting the weaknesses, I was very glad to see that I got a chance to improve. But unexpectedly most of the issues identified are as follows:

Geeks: Aren’t you using Hibernate?
Me: Nope, I wanna utilize the objects which are optimized for and provided by the technology and I have tested them in complex applications.

Geeks: These objects are mess?
Me: Why?

Geeks: Because these are not open-sourced

Me: I admire the benefits of open source but these object are rich, free, built-in, tested and performing well in enterprise applications. I do not very often use them but I found them very useful in such kind of applications

Geeks: You incorrectly applied this pattern; let me show you the documentation.
Me: This pattern like other patterns have different applications, I am following this approach because it performs well in this scenario. This flexibility is also allowed by some experts.

Geek: No, patterns should be followed as is. They are not to be changed for performance or whatever. And remember enterprise applications, built on great technologies like EJB, looks graceful even if they are not enough performant.

Geek: Increase your number of layers like we have did in that application. You have not decoupled enough.

Me: Yes previously I do have the same number of layers but I found it as an overkill so I modified this framework for medium-sized performance-hungry applications.

Geek: And why did you coupled these two major tiers, this is an unacceptable violation of N-Tier Architecture

Me: No, these are still two different layers, but I am keeping them in a single project during development as most of the developers are working on both layers. They still can be deployed on different servers.

Geek: I’m still not satisfied, it is not recommended by our gurus and we follow them because we know they are the best.

Me: They might have recommended it for some different type of project and this approach may be suitable that particular scenario.

Geek: We found their practices the best in all type and size of projects, whatever, it’s not that simple you think it is, you have to add a lot more.


And then I found the key: why people hate patterns, got my point?

Soon, at the same location, I have met with people who say:
"We are successful because we don't develop frameworks and implement patterns. We solve problems, not create”

This kind of concept are erected against the religiousness of pattern-lovers. I was so excited to know that which people are most successful among them.

But what I found was the worst


How to get the worst of all the worlds
The story of ancient war

Software Developers : The Pattern Lovers
Slogans:
Reinvent the wheel
Complexity is honour
Best is always the best
Think out-of-the-box never look inside

Whenever company gets a project the developers are in search of well-hyped patterns and practices. Whatever the projects require, whatever the timelines are, they follow impressions, seeking complexities to passionate their lives. The problem is they want to combine the universal truths they get from their gurus, with the hypes. They get the compliance in few of the cases. It becomes a routine that start with complexity and when you stuck, let the things fly.
They often suggest the solutions they think they should learn. According to their point of view: software projects are to create a difference, even if the project fails, even if they do not add any value, if they implement state-of-the-art technologies, they consider it success.


Software support: the delivery people
Slogans:
We deliver
Quality is a fantasy, don’t talk about it
Ad-hocism
Research is a synonym of time-wasting;
Pattern sucks

Fortunately some of the projects who comply with hyped patterns and rigid practices succeeded to achieve the timelines, thanks fortune. And now the support people are ready to show their quick solutions. They’ll show that the tasks completed by the developers in month was just a matter of days. Thanks to encapsulation; no one knows what’s inside J

Till the day the application is safe from the quick solutions of support staff, it shows some stability. And once it gets the first JUGAR—synonym for a careless ad-hoc solution in Urdu language—the application becomes more addicted to their JUGARs and provides more options for support people to prove their problem solving skills.
[To be continue]