Engineer and architect of large enterprise products here (2 million line Java/C# behemoths that do all sorts of weird and complicated financial shit).
Reality is actually as follows. Not joking I've done this job for 15 years and worked with several large companies including one you mention. Perhaps your experience is in the 1% of "enterprise" companies who have clue but this by far is the majority:
Bold statement here: 99% of the use cases of all these patterns are totally pointless and a waste of money and time. The add nothing to the product, they increase complexity, decrease performance. It's cheaper and more reliable to chop your product up and write each chunk in whatever separately with no official architectural pattern usage system-wide.
Typically in the real world, you're going to end up with:
1. Literally tonnes of DI/IoC code and configuration for an application with an entirely static configuration. This is either in XML or DSL form using builder patterns. Consumes 30 seconds or more to start the application up every time. Aggregate over 50 developers is 16 hours a day pissed out of the window.
2. Proxies for anaemic domain models that are fully exposed. Consumes 30 seconds to generate proxies that do sod all. Aggregate over 50 developers is 16 hours a day pissed out of the window.
3. Leaky broken abstractions everywhere actually destroying the entire point of the abstractions. Makes refactoring impossible and maintenance hell. It's better in some cases that they are not even there and that basic savvy is used over COTS patterns.
4. Acres of copy pasta. Why bother to write a generic implementation when you can copy the interface 50 times and change the types by hand?
5. Patternitis. So we need to use the BUILDER pattern to write the query to connect to the DOMAIN REPOSITORY for the AGGREGATE to call the CODE GENERATOR that fires up the ADAPTER to generate the SQL using the VISITOR PATTERN which farts out some SQL to the database PROVIDER (and a 90 layer stack dump when it shits itself). This is inevitably used in one small corner while everyone in the rest of the system hits a wall in the abstraction and says "fuck it" and writes SQL straight up and skips the layers of pain and because there are no code reviews (because people are all sitting there waiting for their containers to start up whilst posting cats on Facebook).
LINE 10 (remember this)
These things are never rewritten or refactored. They slowly evolve into a behemoth ball of mud which collapses under its own weight to the detriment of customers, a team of enterprise architects (usually from ThoughtWorks etc) usually appear at this point then attempt to sell outsourcing services who will "fix all the shit" for a tiny fee, leave a 200 page powerpoint (with black pages just to fuck your printer up). The company struggles on for a few years and is saved at the last minute by a buy out by a company at an early stage of the cycle who slowly port all the customers and buggy shit to their product platform. Then the team either dissolve and knowledge is lost or they take a cash sum from the sale and start up some ball of shit company that does the same again.
GOTO 10.
That's enterprise 101 because the people that have been hit by the clue sticks know better than to subject themselves to this and do work in SF and SV and London. Me: I'm a masochistic crazy person who wonders every day why I don't just go and write web sites for half the cash or flip burgers because it's less painful.
I agree with you for the most part - what you're describing is rampant abuse by cargo-code programmers that don't know better.
This doesn't mean GoF design patterns are specifically wrong. It's just that they are misused and applied in places they don't belong. When done properly, they should emerge organically as you code without you even realising it (That is to say good design patterns are emergent phenomena in good code, not the other way around).
It also doesn't help that the entire software industry is fixated on single-inheritance OO languages, which tend to encourage ridiculously bad designs.
> It's cheaper and more reliable to chop your product up and write each chunk in whatever separately with no official architectural pattern usage system-wide.
This nails good software design on the head. Don't write large software, write small independent reusable components and combine them together.
This is what dependency injection solves well - When done properly. (If it involves XML or config files it's not done properly).
I think, as Peter Norvig once pointed out, that design patterns are a symptom of an anemic language design. They cost us time and complexity for their benefits. Java wouldn't need half the patterns typically employed to work around the limitation that there are no first-class functions.
Eich himself admitted to avoiding adding classes to Javascript in his interview with Peter Siebel for Coders at Work:
SIEBEL: So you wanted to be like Java, but not too much.
EICH: Not too much. If I put classes in, I'd be in big trouble. Not that I really had time to, but that would've been a no-no.
It's a really good interview and I recommend the book. It seems like Javascript was supposed to be an Algol-syntax over a non-pure Scheme inspired core... but due to constraints was thrown together like most code is when there's a looming deadline.
My point was mostly a sarcastic insight into what it's like for these companies but you're right: there are valid uses and the fundamentals really are spot on. In fact I'm probably #1 fan of Martin Fowler who has spent many years researching, collating and understanding these patterns so they can be communicated to others effectively.
The problem is that it takes literally a decade to actually understand how to use these properly in one specific language (and possibly mostly effectively in another). Until you reach this point, your toolbox isn't filled with the sharpest tools as your team isn't going to be filled with 10 year+ senior staff across the board.
At that point, it goes to shit, every time. These patterns and techniques aren't just tools - they require experience right from the get go and a lot of people just aren't capable of nailing it even in a decade.
When done extremely poorly - enterprise projects can indeed end up as slow behemonths. I agree that this is often the case, but it doesn't mean that the design patterns backing powerful enterprise solutions are to be taken lightly.
Adapter pattern does have a huge, proxies do have legitimate uses, visitor pattern can be made to be extremely powerful. Ofcourse if you have a development sweatshop throwing out these left and right - yes then you will have an abstract mud ball that is impossible to maintain - and in the end defeats the original purpose of these patterns.
> ... totally pointless and a waste of money and time
Sure. Most, but far from all. But let's look at the bigger picture. In the move-fast/break-things corner of the world they write simple software with basic functionality but do it at tremendous speed and sublime efficiency.
And then they go out of business.
So I guess most of lines of code written anywhere are a waste of time and money. But that's just how it is. A more interesting question to ask is how much money is wasted and how much is made by both kinds of software development. I don't know the answer, but it's certainly not clear cut.
Reality is actually as follows. Not joking I've done this job for 15 years and worked with several large companies including one you mention. Perhaps your experience is in the 1% of "enterprise" companies who have clue but this by far is the majority:
Bold statement here: 99% of the use cases of all these patterns are totally pointless and a waste of money and time. The add nothing to the product, they increase complexity, decrease performance. It's cheaper and more reliable to chop your product up and write each chunk in whatever separately with no official architectural pattern usage system-wide.
Typically in the real world, you're going to end up with:
1. Literally tonnes of DI/IoC code and configuration for an application with an entirely static configuration. This is either in XML or DSL form using builder patterns. Consumes 30 seconds or more to start the application up every time. Aggregate over 50 developers is 16 hours a day pissed out of the window.
2. Proxies for anaemic domain models that are fully exposed. Consumes 30 seconds to generate proxies that do sod all. Aggregate over 50 developers is 16 hours a day pissed out of the window.
3. Leaky broken abstractions everywhere actually destroying the entire point of the abstractions. Makes refactoring impossible and maintenance hell. It's better in some cases that they are not even there and that basic savvy is used over COTS patterns.
4. Acres of copy pasta. Why bother to write a generic implementation when you can copy the interface 50 times and change the types by hand?
5. Patternitis. So we need to use the BUILDER pattern to write the query to connect to the DOMAIN REPOSITORY for the AGGREGATE to call the CODE GENERATOR that fires up the ADAPTER to generate the SQL using the VISITOR PATTERN which farts out some SQL to the database PROVIDER (and a 90 layer stack dump when it shits itself). This is inevitably used in one small corner while everyone in the rest of the system hits a wall in the abstraction and says "fuck it" and writes SQL straight up and skips the layers of pain and because there are no code reviews (because people are all sitting there waiting for their containers to start up whilst posting cats on Facebook).
LINE 10 (remember this)
These things are never rewritten or refactored. They slowly evolve into a behemoth ball of mud which collapses under its own weight to the detriment of customers, a team of enterprise architects (usually from ThoughtWorks etc) usually appear at this point then attempt to sell outsourcing services who will "fix all the shit" for a tiny fee, leave a 200 page powerpoint (with black pages just to fuck your printer up). The company struggles on for a few years and is saved at the last minute by a buy out by a company at an early stage of the cycle who slowly port all the customers and buggy shit to their product platform. Then the team either dissolve and knowledge is lost or they take a cash sum from the sale and start up some ball of shit company that does the same again.
GOTO 10.
That's enterprise 101 because the people that have been hit by the clue sticks know better than to subject themselves to this and do work in SF and SV and London. Me: I'm a masochistic crazy person who wonders every day why I don't just go and write web sites for half the cash or flip burgers because it's less painful.