Found in 4 comments
by specialist
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

Original thread
by specialist
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

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.

Original thread
by specialist
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.

Original thread
by specialist
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.

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.

Original thread

Looking for a good book? Subscribe to the weekly newsletter.