Beneficial Relationships
...Of The Technical Kind
The TF? definition of design is, “Beneficially Relating Elements”. If elements are defined as, “The limits of change propagation,” then what are the relationships between elements and how do elements benefit from those relationships?
I can’t answer these questions. Yet. Figuring it out is part of writing the book (I’ll be announcing the details of paid subscriptions and a rough book timeline soon).
What I’m pretty sure I know:
Scale matters. The relationships between functions are qualitatively different from the relationships between modules or services. I expect some invariants to hold, like power laws.
Simplicity. I don’t expect the answers to either “what are the relationships?” nor “what are the benefits conferred?” to be infinitely complicated. More like the four flavors of function-scoped variables.
Surprises. Some of what comes of this inquiry will be shocking, even after 50 years or writing programs. That’s the fun part!
I have taken to defining design as the act of organizing source code in order to reduce the cost of changing it, which typically means reducing the cost of figuring out how to change it safely and accurately.
This tends to translate into "make it easier to find/notice things" and "make it harder to miss related things". "Good" design helps us figure out which parts to try to change and which parts to try to leave alone, while tests help us discover surprises sooner.
This seems quite compatible with your formulation of relating elements beneficially.