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.