The result is a discipline that has transformed into managing uncertain outcomes in large heterogeneous models, i.e. complexity theory, rather than reducing everything to balls-and-sticks. Meadows was famous for devising "12 basic places to intervene in a system", nowadays the focus is on hedging bets adequately such that interventions don't catastrophically fuck up.
That said, some of the basic tooling is still flexible enough for basic business problems and some of the old gems are able to explain important concepts found in other fields without getting bogged down in the math.
https://www.amazon.com/Early-Retirement-Extreme-Philosophica... is my favourite, it's not about retirement, it's about using systems thinking to devise a robust lifestyle.
https://www.amazon.com/Introduction-General-Systems-Thinking... will make a good complement to Meadows and should give you a calculus to rigorously think of systems with.
https://www.amazon.com/Introduction-Cybernetics-W-Ross-Ashby... for its explanation on entropy, I mean requisite diversity, which will you give you an approximate mental quantity of how "powerful" any given system is.
https://www.amazon.com/Sciences-Artificial-Herbert-Simon/dp/... and https://www.amazon.com/Design-Rules-Vol-Power-Modularity/dp/... I haven't read either of these, but Herb Simon is extremely influential and has great thoughts on the notion of system hierarchies (nearly-decomposable systems is a great concept for design). The second book is about the properties of modular systems, which will help grok the reasoning behind a lot of refactoring techniques.
Design Rules, Vol. 1: The Power of Modularity http://www.amazon.com/dp/0262024667
I'll chew on your statements about the success of Python. Though my first love was LISP, I'm now far more comfortable leaning on static typing and composition.
The best book on software design I've ever read was written by two economists.
Design Rules: The Power of Modularity
This book didn't change how I program so much as changed how I think. Like the difference between making and criticizing art. Whereas SICP gave me new mental models, Design Rules gave me new philosophies. More like Design of Everyday Things did.
1) Assemble non-experts, non-stakeholders
2) Misidentify problem
3) Establish quorum
4) Do not communicate decisions
5) Everyone runs off in separate directions
6) Assign blame
Given the challenges of organizational psychology (aka herding kittens), where trying harder won't change outcomes, I support the strategy of multiple competing teams, as detailed in the book Design Rules: The Power of Modularity.
I asked Grady Booch "What is software architecture?"
He answered "Software architecture is what software architects 'do'."
At that point I stopped caring.
Until I found the book Design Rules: The Power of Modularity. http://www.amazon.com/Design-Rules-Vol-Power-Modularity/dp/0...
It is the sole source I've ever encountered that had anything useful, actionable, insightful, informative, rigorous, etc.
Alas, I've never been able to synthesis Design Rules' methodology into any of my efforts.
Because what I do is software craftsmanship. I've designed some awesome stuff (and a lot of crap). But nothing rigorous, repeatable, explainable.
For a few years, I bought every software design book I could find. Some of them actually good. But the ones claiming to be about "software architecture" are really describing software craftsmanship. Describe as in descriptive, vs prescriptive.
From memory, Design Rules states that architecture is the set of visible design choices in a product. The entire thesis of the book, backed by oodles of case studies and data, is that deciding where the lines between subsystems, the interfaces, and the allowable parameters for those interfaces, is architecture.
PS- Just read the OP. Nothing actionable. Move along.
Get dozens of book recommendations delivered straight to your inbox every Thursday.