5 ms·

i've cultivated the perception of what op calls design pressure my whole career as the primary driver behind code and her shape. i think it's the most important

i've cultivated the perception of what op calls design pressure my whole career as the primary driver behind code and her shape. i think it's the most important aspect of a successful architecture, and it's purely intuition based, which is also why there's no silver bullet. i've seen people take most well intended best practices and drive them into the ground because they lack the design pressure sense. i believe that design pressure sense is a form of taste, and like taste it needs to be cultivated, and that is can't be easily verbalized or measured. you just know that your architecture is going to have advantageous properties, but to sit down and explain why will take inordinate amount of effort. the goal is to be able to look at the architecture and be able to see its failure states as it evolves through other people working with it, external pressures, requirement changes, etc. over the course of 2, 3, ... 10, etc. years into the future. i stay in touch with former colleagues from projects where i was architect, just so that i can learn how the architecture evolved, what were the pain points, etc. i've met other architects who have that sense, and it's a joy to work with them, because it is vibing. conversly "best practices or bust" sticklers are insufferable. i make sure that i don't have to contend with such people.

layer8 1y ago
This reminds me of the concept of “forces” [0][1][2] in design-pattern descriptions. To decide for or against the use of a given design pattern, or to choose between alternative design patterns, one has to assess and weigh the respective forces in the particular context where it is to be used. They are called forces because they collectively pull the design in a certain direction. Just a different physics analogy versus “pressure”. [0] https://www.cs.unc.edu/~stotts/COMP723-s13/patterns/forces.html https://www.cs.unc.edu/~stotts/COMP723-s13/patterns/forces.h... [1] https://www.pmi.org/disciplined-agile/structure-of-pattern-pages#Patterns https://www.pmi.org/disciplined-agile/structure-of-pattern-p... [2] Chapter 19 in “Pattern languages of program design 2”, ISBN 0201895277
skydhash 1y ago
Code is for communicating with humans primarily, even though it needs to be run on a machine. All the patterns, principles, and best practices is to ease understanding and reasoning by other people, including your future self. Flexibility is essential, but common patterns and shared metaphors work wonders.
- rowanG077 1y ago
  That's terribly short sighted. You can have a very clear architecture and code which cannot support the use cases required without almost starting from scratch.
  - semicolon_storm 1y ago
    You can also have the most flexible system ever designed, but if the rest of your team doesn't understand it then good luck implementing that required use cases
    - rowanG077 1y ago
      Sure, both extremes are shortsighted. I wasn't arguing for that, to be clear. I'm just saying clarity and ivory tower architecturing has little value if your system can't actually support the intended use case. Which is what the person I was replying to said with "Code is for communicating with humans primarily, even though it needs to be run on a machine.". If the primary purpose is communication with other humans we wouldn't choose such awkward languages. The primary purpose of code is to run and provide some kind of features supporting use cases. It's really nice however if humans can understand it well.
- immibis 1y ago
  That aphorism is completely incorrect. Code is primarily for communicating with a machine. If the purpose was to communicate with humans, we'd use human languages. Lawyers do that. The code does also need to be understandable by other humans, but that is not its primary purpose.
  - skydhash 1y ago
    So why do we have Java, Kotlin, Scala, Groovy, and Clojure, all targeting the JVM? And many such families? The only thing that matter to the machine is opcodes and bits, But that's alien to human, so we map it to assembly. Any abstractions higher than that is mostly for reasoning about the code and share that with other people. And in the process we find some very good abstractions which we then embed into programming languages like procedure, namespacing, OOP, patterns matching, structs, traits/protocols,... All these abstractions are good because they are useful when modeling a problem. The some are so good then it's worth writing a whole VM to get them (lisp homoiconicity, smalltalk's consistent world representation,...)
osigurdson 1y ago
Zen and Art of Motorcyle maintenance is a good reference. Also, it is good to remember what game is actually being played. When someone comes up with a popularizes a given "best practice", why are they doing so? In many cases, Uncle Bob types are doing this just as a form of self promotion. Most best practices are fundamentally indefensible with proponents resorting to ad-hominem attacks if their little church is threatened.
- fud101 1y ago
  That book is such a struggle in the beginning. I was waiting for it to get to the point but I never got there.

layer8 1y ago

This reminds me of the concept of “forces” [0][1][2] in design-pattern descriptions. To decide for or against the use of a given design pattern, or to choose between alternative design patterns, one has to assess and weigh the respective forces in the particular context where it is to be used. They are called forces because they collectively pull the design in a certain direction. Just a different physics analogy versus “pressure”. [0] https://www.cs.unc.edu/~stotts/COMP723-s13/patterns/forces.html https://www.cs.unc.edu/~stotts/COMP723-s13/patterns/forces.h... [1] https://www.pmi.org/disciplined-agile/structure-of-pattern-pages#Patterns https://www.pmi.org/disciplined-agile/structure-of-pattern-p... [2] Chapter 19 in “Pattern languages of program design 2”, ISBN 0201895277

skydhash 1y ago

Code is for communicating with humans primarily, even though it needs to be run on a machine. All the patterns, principles, and best practices is to ease understanding and reasoning by other people, including your future self. Flexibility is essential, but common patterns and shared metaphors work wonders.

rowanG077 1y ago
That's terribly short sighted. You can have a very clear architecture and code which cannot support the use cases required without almost starting from scratch.
- semicolon_storm 1y ago
  You can also have the most flexible system ever designed, but if the rest of your team doesn't understand it then good luck implementing that required use cases
  - rowanG077 1y ago
    Sure, both extremes are shortsighted. I wasn't arguing for that, to be clear. I'm just saying clarity and ivory tower architecturing has little value if your system can't actually support the intended use case. Which is what the person I was replying to said with "Code is for communicating with humans primarily, even though it needs to be run on a machine.". If the primary purpose is communication with other humans we wouldn't choose such awkward languages. The primary purpose of code is to run and provide some kind of features supporting use cases. It's really nice however if humans can understand it well.
immibis 1y ago
That aphorism is completely incorrect. Code is primarily for communicating with a machine. If the purpose was to communicate with humans, we'd use human languages. Lawyers do that. The code does also need to be understandable by other humans, but that is not its primary purpose.
- skydhash 1y ago
  So why do we have Java, Kotlin, Scala, Groovy, and Clojure, all targeting the JVM? And many such families? The only thing that matter to the machine is opcodes and bits, But that's alien to human, so we map it to assembly. Any abstractions higher than that is mostly for reasoning about the code and share that with other people. And in the process we find some very good abstractions which we then embed into programming languages like procedure, namespacing, OOP, patterns matching, structs, traits/protocols,... All these abstractions are good because they are useful when modeling a problem. The some are so good then it's worth writing a whole VM to get them (lisp homoiconicity, smalltalk's consistent world representation,...)

osigurdson 1y ago

Zen and Art of Motorcyle maintenance is a good reference. Also, it is good to remember what game is actually being played. When someone comes up with a popularizes a given "best practice", why are they doing so? In many cases, Uncle Bob types are doing this just as a form of self promotion. Most best practices are fundamentally indefensible with proponents resorting to ad-hominem attacks if their little church is threatened.

fud101 1y ago
That book is such a struggle in the beginning. I was waiting for it to get to the point but I never got there.