I got out after butting heads with him constantly, and I don't think said company ever shipped anything meaningful in his entire tenure here.
When I worked there I was a product guy, and it took me an embarrassingly long time to understand why I didn't fit in... but yeah, I didn't last long.
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.
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).
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.
DDD Europe by all accounts was a resounding success. We’ve replaced older architecture activities like data modeling first with event modeling and Domain-Driven Design.
We’ve learned to embrace monoliths when appropriate and reduce complexity with bounded contexts.
We have phenomenal testing capabilities that didn’t exist 20 years ago.
We have a myriad of data storage tools.
We understand front-end engineering from an information architecture perspective.
We can design detailed architectures in tools like LucidChart very quickly with detailed solution details.
I’ve been at this for 40 years and I’ve never felt better about being a software architect.
Lots of people make bad designs today, sure, but it's not for a lack of formal methodologies, because average design quality was way worse back in the design patterns 'n' UML days.