I strongly dislike them. Here’s why:

I’ve seen more horrendous programming sins committed in the name of patterns than almost any other possible justification. “Optimization” is close, but somehow I’m more forgiving of that - at least the developer is attempting to be concerned with the operation of the application as opposed to the padding of his resume.

There’s nothing inherently wrong with patterns. They are the distillation of experience into easily recognizable chunks that can be applied to common, frequently occurring segments of problems. You can see them everywhere - in mathematics, physics, mechanics, and yes, even in computer science and programming.

They are, however, a second order tool. They are what you use to refine and speed up your development process. They’re not a substitute for actual understanding of fundamental programming and algorithm design principles. Nor do they take precedence over first order principles.

What am I talking about? Let me give you an example. Here’s the real world:

A senior developer, with 2 developers reporting to him, designed and implemented a subsystem. The need arose for what seemed to be a minor modification, and the developer responded with an estimate of two weeks. We were puzzled - the change had every appearance of being simple. I’d have thought less than a day.

So we dug into the implementation. The developer presented the design of the subsystem. He had used EJBs along with the (name withheld to protect the innocent) pattern. The design hung together fairly well. But there was one glaring problem:

The entire subsystem could’ve been implemented with a fraction of the complexity by using a simple servlet connecting to JDBC. If you wanted to be fancy you could’ve used some abstraction of the database. That’s it. Really quite simple.

We gently pressed the developer on his design choices and why he seemingly favored the complex over the simple in almost every instance. He responded with the usual list of suspects: transactions, scalability, maintainability, ease of understanding.

Good list. Here’s the problem: we didn’t need transactions. Scalability doesn’t hold up: look at the highest scaling systems and you’ll see they’re not EJBs. In any case, servlets would’ve scaled just fine for our purposes. Maintainability and ease of understanding are easy to gauge: it’s easier to understand and maintain less lines of code. Less lines of code good, more lines bad.

Then we looked at the actual code. Good Lord. Copy and paste of major pieces into a several files. Justification? Horrible misuse of the poor, innocent factory pattern. Lines of code? Many. Many. Innocent patterns slaughtered everywhere.

We actually spent quite a bit of time with the developer, attempting to reform him. He was a good, smart guy, worth saving. Unfortunately we were unsuccessful, primarily because he sincerely believed he was right - he was using EJBs and patterns. How could the simple, lowly servlet be a better path?

At the end one of our other developers rewrote the entire subsystem in his spare time in far less than two weeks. Lines of code? Something like 1/5th to 1/10th of the original. Faster. Understandable. Simple. The original developer moved on to create many many lines of code for some other company.

Is this really a damnation of patterns or the case of a bad developer? My point is, this guy was not born a bad developer. He was quite smart, and could’ve been useful. There are many of this guy running around. I’ve seen them.

The problem is, he embraced second order techniques, EJBs and patterns, in place of a first order principle, simplicity.

So when you go out there preaching patterns to the masses, remember the real world. And remember boys and girls: Simple is good. Less lines of code good. You don’t need to throw around the latest acronyms and pattern names to be a 10x programmer. Trust me, I know a lot of those guys too, and most of them couldn’t tell you what that fancy pattern name you just dropped means.