I know what you're getting at here. You just can't put it in words. And because you can't put it in words, you're unable to see the big picture. To put it plainly you're talking about this:
For a specific context how do we organize and modularize code to maximize reuse-ability for a uncertain future with uncertain requirements?
You think that this problem can't be formalized. And this is basically what you're trying to elucidate into words with your post. It's that simple.
However, this is the exact problem I am saying is ripe for formalization.
This is what I'm talking about and you've missed my point.
Who says we can't formally define what a module is? and who says we can't formally define what it means for a module to be more re-useable? Who says we can't formally define program requirements? From these axioms we can define a calculus that allows us in the best case to calculate the most optimal program and in the worst case at least be able to know whether one design is "better" than another design.
Instead what the industry does is write blog posts about a metaphor. Then give a bunch of examples of why that metaphor is cooler then some other design pattern. Then repeat the same thing every couple of years.
Let me frame it for you so that you can wrap your head around what I'm talking about. Given tic-tac-toe we can formally play the game in a way we can never lose. This is definitely not a design problem and one that can be calculated. Very easy to see why this is the case because of the limited primitives your dealing with in tic-tac-toe.
The "problem domain" defined within a computer is NO different. In computers You have a limited set of primitives in a rule based playing field: assembly language. The objective is not 3 in a row but whatever formal requirements your program has. Within this problem space there is either one or several configurations of assembly instructions that will fulfill that problem domain according to a formal definition of "optimal". That is the spirit of the formalization I'm talking about. A more complex tic-tac-toe problem.
The notion of what it means for an algorithm to be faster has been formalized. So if the problem domain was "how do you sort a list of shoe sizes in the fastest way possible?" then we ALREADY have a formal and definitive way to determine the best possible configurations of assembly instructions to achieve this goal. The problem is solved partially for speed. Picking a faster algorithm is no longer a design choice.
The next step is to formalize the notion of modularity and program organization and bring it out of the fuzzy realm of design and architecture and into a more formal realm where things are exactly defined. We came up with a number for speed (O(N)), who says we can't come up with a number for modularity?
I don't blame you for making this mistake. "Luck" itself use to be a design problem. Intuitively it's very hard to think of the concept of "luck" as a measurement problem. It was utterly incomprehensible for a typical person to even visualize luck as something that can be calculated. It was only after the development of probability theory that people were able to see how it can be done, it is much harder to predict formal possibilities of a topic before the formalization has actually been done.
It's the same thing for module organization. "Design." so to speak
>Architecture is just a disciplne of making your life suck less later. It's not an easy discipline, and (clearly) not a
You can't even define what it means to make you life "suck less." Are you talking about algorithmic speed? Because that's been formalized. Are you talking about less bugs? Because smaller error surface areas have been partially formalized with type theory and Rusts borrow checker...
Are you talking about organization of modules? Because if you're talking about a formal way to organize modules, well that hasn't been done. But don't let that limit your mind into thinking it can't be done.
Especially don't let that limit your mind into falling under the illusion of thinking that all of these endless circles and design philosophies that go in vogue and out of vogue throughout the industry are actually doing something to improve the software as a whole. If you ever wanted a good example of history repeating itself software design is the perfect example.
In simple terms: the discipline of "architecture" is not well understood because it has NOT been formalized. At this point it's borderline fraudulent to even call it a discipline. Call it a career title, sure, but don't try to think of this stuff as anything on the same level as the sciences.