Hacker News Reader

Hacker News

Comment by edoceo | Hacker News Reader

Parent Full thread

edoceo

Oh man, patterns of enterprise, it's like 20 years old now! I really like Martin's work. Worth every penny

View on HN

id rather argue that his book was one of the major reasons why we ended up in over engineering hell.

i was affected by that as a junior and even medior as well and i caused a lot of harm :-)

luckily i learned to step away from it.

Oh, see, I saw that book after watching dozens of dot-com companies re-implemting common patterns (poorly). Basically under-engineering heck. So, once we had the book we could shift the conversation and use common terminology.

The discipline is, of course, knowing which spells to cast and when. And it's super useful to see the scroll of common spells.

A problem in a lot of cases is that for some people, the discipline is about casting spells as opposed to solving problems. It doesn't take a lot of these people to damage projects, but they exist independent of pattern books.

If I was going to complain about engineering hell, it'd be about how shallow we investigate these areas. We stop at the immediate technical events, or inappropriate technology choices, instead of getting to the motivations behind it. This gets into a qualitative area that HN readers tend to want to avoid, but these flaws are with the humans and their circumstances.

I'd argue that the over-engineering hell preceded this book, with every tiny J2EE project using a full 3-tier stack, incl (but not limited to) stateful EJBs, session EJBs, countless JSPs, DAO layers, god only know what else.

It was this book that actually revealed, in patterns, the bigger picture, where it was all going wrong, and the alternatives. This book and Spring v1.0 go along together in my mind.

BTW (and OT), another underrated Fowler book in a similar vein is "Analysis Patterns", another 10k-ft view of common business problems.

I'm a little torn on this one. On the one hand I see it, because it feels like patterns books made the limitations of C++/Java/C# seem respectable, even desirable. Norvig observed this with his talk on patterns in dynamic languages (p. 10 of https://norvig.com/design-patterns/ summarizes this).

On the other hand, I have found his work to be useful in selling approaches to others. There were times where I did a design, then browsed the patterns books to find names for what I was doing to "make it respectable."

I've done the opposite, disguising something that is a named pattern as anything but a factory to prevent structure-avoidant zealots from knee-jerk reacting to the word in a PR.

Can you provide some concrete examples?

I.e. pattern X was recommended for a scenario Y, but ended up in over-engineering hell for Z.

IoC is one that comes to mind. It greatly simplifies testing, but the engineering (before we had libraries for it) was ridiculous to implement.

Usable IoC actually can be implemented in just 4-5 classes. Yes, it won't be as powerful as Guice but for some (or a lot?) of applications it's probably enough.

[0] http://misko.hevery.com/2010/05/26/do-it-yourself-dependency...

[1] http://blacksheep.parry.org/wp-content/uploads/2010/03/DIY-D...

Compared to just creating your own dependencies inside a class and not writing interfaces, IOC adds a great deal of complexity.

You don't have to write interfaces to have dependency injection. You can and should declare all your dependencies as constructor parameters. If you create them inside a class you'll permanently lock the two together, thus making it a testability nightmare.

I think this is a good one. Most recent Java/C# systems would have a full IoC container, but have no dynamically selected components (which is how frameworks like Dagger -https://dagger.dev/ - can exist). A lot of runtime reflection/calculation gets done for something that can be known at compile time.

I was exactly the same in my earlier dev days! I'd learn about a pattern, think it was the greatest thing since sliced bread, and see uses for it everywhere... where it really wasn't suitable at all. I was like a builder with only a hammer - everything looked like a nail!

I ended up making a lot of things a lot more complex than they needed to be, or/and a lot less performant than they could be.

At some point, lot's of people seemed to come to the same realisation - worshipping design patterns is a bad idea. Around this time I first heard about "cargo culting".

These days my motto is "no dogma" (well, except about not being dogmatic ;), and I think it serves me well.

I think I know what you're saying. I remember that time, around the birth of Java. But I also remember that we were trying to solve real problems that aren't such big problems anymore: modularization, dependency management, large codebases with crude editing tools, SW delivery and distribution in the age of diskettes!

It turns out that developing large systems in static languages with heavily constrained libraries is difficult. Rapid zero-cost distribution and decentralized storage AND GUIs have really changed the field. Does anyone even call themselves a SW Engineer anymore?

I never had the courage of say this...

I'll plant a midpost flag and say, while it shouldn't be revered as a bible of eternal truths, it did document and progress the discussion on many things.

I think Fowler does a good job of identifying and classifying things, but that hasn't necessarily made IT / Enterprise all that simpler. What has made "progress" in IT has fundamentally been programmers treating more and more things like code and automating the hell out of everything.

Reply on news.ycombinator.com