Ok, so in practice you are saying that no good programming paradigm exists. Where do we go from there?

I agree no paradigm is particularly great for beginners - OOP leads to junior devs separating their code prematurely/inaccurately, writing horrendous inheritance trees etc., functional programming can lead to some really opaque code that feels like you're trying to solve a puzzle when reading it. I do think good principles exist however:

- try to write code that can be easily unit tested

- composition over inheritance

- immutable over mutable + avoid side effects

- avoid recursion unless your data is recursive

etc. etc.

Well, I don't think anything changed. We already knew there was no Silver Bullet.

To paraphrase Brooks, no pattern or methodology is gonna make development "more productive, more reliable or simpler". All patterns and methodologies require a skilled practitioner, but someone skilled enough can even eschew them and still make good software, so in the end they don't really matter.

The point of patterns/methodologies is purely to facilitate communication between experts, not to guide.

In the end, good software is not about following recipes, especially complex recipes. It's a craft.

As for where do we go, what we need is the foundation for personally re-discovering and internalising those same methodologies and patterns, rather than blindly following them. Sweezyjeezy already enumerated some ideas above, and I have done the same in the past: https://news.ycombinator.com/item?id=27987498

Certainly no good general purpose programming paradigm exists. Nor will it.

The more general purpose it purports to be the vaguer and more misapplied it will end up being.

DDD could be a lot better as a movement if it tried to limit its scope a bit.

Wait until the market stabilizes and new dev don't outnumber more senior ones 10:1.

Until then, we have to stick to patterns that are very simple, easy to teach and have wide pits of success. We also have to lean heavily on systems that easy to replace and easy to refactor, and can be managed by the few very experienced devs. That's why platforms like Ruby on Rails did so well, even though they can be divisive.

> for me, whether a particular programming paradigm is 'good' or 'bad' for an organisation comes down to: "what will my least senior developer do with this?"

I wish ideas like these were more prevalent or that, at least, people considered that in many cases the quality of a method or practice is not an intrinsic attribute, but a matter of suitability to a particular environment.

That's the problem I have with agile enthusiasts in general. I've seen agile methods operating wonders on many projects, but I've seen it failing on much more, and it's completely OK to assume that the method has its assumptions/conditions/limitations but enthusiasts, instead, blame the company and practitioners for not having understood and applied it appropriately.

That's not a good heuristic IMO; it boils down to evaluating every item in terms of what a toddler could do with it. There are situations in which it makes sense, but you can't build a civilization like that. The correct way is to keep toddlers / "least senior developers" away from powerful/dangerous things, until they grow up to the point they can be taught to use them responsibly.