The promise of Design Patterns (tm) is that you can systematically learn to organize your code. The article argues that only experience does.

If it were that easy, you could write a compiler compiler that knows all the “design patterns” and generates perfect solutions for all problems.

Remember the 239th Rule of Acquisition, “Never be afraid to mislabel a product.” That goes for methodologies, too. If they could get away with it, they would probably say it cures baldness, too.

I believe that would actually be possible if we had a standardized problem specification format.

So it would boil down to the quest for the “sufficiently smart problem specification format”. OK, aren't programming languages standard problem specification formats? Why do you suppose there are different PLs? Right, because all problems _can't_ be specified advantageously in the same format. Which brings you full circle to where you started. That's by no means a discouragement. If you invent a PL that's better than what we have now, it's still progress. But, to use a famous quote, “there is no silver bullet”.

But design patterns are horrible at organizing code. They have a much higher chance of introducing unneeded complexity.

It should be no surprise that almost every single design pattern can be replaced with a simple lambda in languages supporting them.

Design patterns are excellent at creating the illusion of organisation.

I recently had to modify someone else's Mac app. On the surface it looked like a textbook example of successful use of design patterns. Everything was highly modular, functions were simple, there was clear separation of concerns, controllers and views were distinct, and so on.

Problem was, the key features were still baked in and hard to modify. So while it looked modular, it wasn't - the affordances were fixed and there was no way to generalise them without pulling apart at least a couple of levels.

IMO it's not abstract organisation that matters. Organisation is only good if it makes it easier to achieve clearly-defined goals and benefits. You need to know what the goals are, and make some guesses about what they might be in the future. Otherwise you're just putting stuff in layers and boxes and drawing arrows everywhere for no good reason.

Well said. I would add to this that design patterns do not discern between simple concerns and cross-cutting concerns and those are key elements to get right at the organizational level.

Features are by definition almost always cross-cutting concerns in that they touch half the systems that makes up the application.

Even if your systems are pure isolated islands properly decoupled from each other, they can still be tangled back into a spaghetti mess when wiring it all together.

Furthermore, design patterns define data structures rather than data flow, even the behavioral ones, making them horrible at organizing the application's features.