HN Books @HNBooksMonth

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.

⬐ wolverine876

So why are you holding back on us? :) What are the main trade-offs?

⬐ specialist

Heh. Just what you'd guess. Interfaces allow separation of concerns, parallel dev efforts, competition. Integration allows optimization, at greater risk.

Their core contribution is modeling the options with net present value (NPV) to remove the guess work.

--

Tangentially...

They also explain the dependency structure matrix (DSM), a tool for modeling and visualizing architectures.

One big takeaway for me was their explanation of "complexity catastrophe". The crossover point when the cost of change exceeds the benefit. A metaphor superior to most interpretations of "technical debt", IMHO.

So when you have a DSM, these kinds of problems pop out, can't be ignored.

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.

⬐ scroot

Seconding the recommendation of Herbert Simon, especially Sciences of the Artificial.

⬐ llamaz

Very interesting. Can I ask from which background you came to be interested in systems (e.g. biology or electrical engineering)?

⬐ bordercases

Philosophy and Design, I wanted to understand the world in the most general way possible to be flexible enough to adopt to any problem. I also like thinking clearly and being right

⬐ pella

"complexity theory" is very important!

-----

my favorite: New England Complex Systems Institute (NECSI) website!

* About Complex Systems : "Concept Map" http://www.necsi.edu/guide/concepts/conceptmap.html

* Learn: http://necsi.edu/learn.html

* "Dynamics of Complex Systems" - Full PDF: http://necsi.edu/publications/dcs/index.html

* NECSI Seminar Video Library: http://www.necsi.edu/events/vidlib/

* Research: http://necsi.edu/research.html

⬐ pureGuano

Came here to post Dynamics of Complex Systems. Just the information on renormalization groups and multi-scale behavior makes it worth the time. And it's Free!

⬐ bordercases

As much as I love NECSI and Santa Fe Complexity Institute, the way the science is taught is a bit of a grab bag. Way too much emphasis on models that aren't widely applicable to engineering problems, like cellular automata.

Nassim Taleb's collaborations with NESCI are worth their weight, though, and W Brian Arthur out of SFI produces works that I consider actionable for CTOs to get a conceptual handle on their craft. UoM's Scott E Paige is also a good resource on Complex Adaptive Systems in a way that is more unified.

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.

⬐ nickpsecurity

Thanks for the link. Let me repay you with one:

http://www.amazon.com/Design-Essays-Computer-Scientist/dp/02...

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.

⬐ None

None