Design Rules, Vol. 1: The Power of Modularity [2000]

https://www.amazon.com/Design-Rules-Vol-Power-Modularity/dp/...

Formal definitions for interfaces and so forth. Completely changed my mental model for my work.

Paraphrasing from book (from memory): "Architecture" is the set of visible design choices.

Design Rules is to software methodology what Diffusion of Innovations is to product development.

There is some overlap between Design Rules and Diffusion of Innovations, of course. They're compliments.

Please forgive the hi-jack...

FWIW, the book Design Rules: The Power of Modularity systematically explores the tradeoffs.

https://www.amazon.com/Design-Rules-Vol-Power-Modularity/dp/...

Written by two economists, it's the only prescriptive definition of architecture that I've managed to find. Influenced me deeply.

Basket of NPV style hedges are The Correct Answer™. Meaning, try a bunch of stuff, with some reasonable resources and constraints, see what works.

I like the explanation and rationale given in Design Rules https://www.amazon.com/Design-Rules-Vol-Power-Modularity/dp/..., though there's plenty of others.

https://en.m.wikipedia.org/wiki/Net_present_value

Very interesting idea.

You might like the book Design Rules: The Power of Modularity. https://www.amazon.com/Design-Rules-Vol-Power-Modularity/dp/...

I'm going to ponder how to design the game artifacts.

"...wish it had a name..."

IIRC, I think first read the phrase "complexity catastrophe" in the book Design Rules: The Power of Modularity. Per the authors, it's when a system becomes so complex (interdependent) that the cost of any further changes far outweigh the expected benefit.

https://www.amazon.com/Design-Rules-Vol-Power-Modularity/dp/...

The box-and-arrows paradigm for systems, built in the 50s and enjoying popularity briefly in the 80s, is overrated, and has been outmoded by the likes of complexity theory. This is due to the fact that box-and-arrows systems like those made by Club of Rome to predict civilizational collapse carry strong assumptions as to the nature and structure of underlying variables and as such become very brittle as the size of the system scales. The norm is not the closed-loop circuit models that initially inspired systems thinking, but open-loop energetic models where any structural element is more like a rarified pattern than an ontological atom.

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.

Good luck.

Nice cite, fun to think about, thanks. Will compare with NPV options based strategy proposed in Design Rules.

Design Rules, Vol. 1: The Power of Modularity http://www.amazon.com/dp/0262024667

Good article. Interfaces and modularity are core concepts, worthy of much attention. Especially questions like how to do functional decomposition, finding the right abstractions, and good interface design.

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

http://www.amazon.com/Design-Rules-Vol-Power-Modularity/dp/0...

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.

Awesome. Thank you. Very similar to the "process" I've witnessed and documented. From memory:

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

7) Repeat.

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.

http://www.amazon.com/Design-Rules-Vol-Power-Modularity/dp/0...

I met Grady Booch at the kickoff meeting for the Society of Software Architects (or some such). OOPSLA 1998 in Vancouver.

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.