[snapdaddy]

I don't think it was software architecture, UML or design patterns that was bad. I think the 'Open-Closed Principle' is one of the worst ideas to ever gain popular acceptance.

For anyone who didn't live through that time, the Open-Closed Principle states that software should be open for extension, but closed for modification.

However, you could also rephrase that principle to be: 'you should always prematurely abstract your designs'.

I think if abstraction was viewed as a negative to be avoided unless necessary, software architecture would have been far better off.

To be fair, premature abstraction is a lot of fun for those that do it. It's just those that follow who aren't so keen.

[WuxiFingerHold]

That is an import perspective. I've always struggled to understand why (esp. in the Java enterprise world) things were so complex. It took me a while to see through it and now I create abstractions when I need them, not just in case. That's why I don't like things like Clean Architecture.

E.g. I don't create an abstraction in case I someday need to switch the database from SQL to NoSQL, but when I need the abstraction right now for an alternative implementation (e.g. mocks for testing).

[carlmr]

This is very on point. Premature abstraction has always a struck me as way now evil than what premature optimization can create.

Every class has an interface abstraction, or worse inheritance hierarchy, that adds friction to change, even though it's the only implementation.

When something similar comes along it's pressed into that shape, because the abstraction is already there.

It's like this meme video where it's hard to watch all the round and triangular pieces being fit in the square hole.

And the problem is that while software is more flexible than traditional architecture, hence soft, the complexity limit is also soft or virtually non-existent. So in software it's worth more to be simple and flexible than to have a plan that's long and detailed.