13 ms·

Design Pressure: The Invisible Hand That Shapes Your Code

212 points by NeutralForest 1y ago

1317 1y ago
[video]
da39a3ee 1y ago
I'm not sure I'd take design advice from someone who thought attr.ib and attr.s were a good idea. On the other hand he points out that DDD is a vacuous cult, which is true.
- wilkystyle 1y ago
  > I'm not sure I'd take design advice from someone who thought attr.ib and attr.s were a good idea Can you elaborate?
  - hynek 1y ago
    that's a reference to my attrs library which is what data classes are based on. It originally used @attr.s class C: x = attr.ib() as its main api (with `attr.attrs` and `attr.attrib` as serious business aliases so you didn't have to use it). That API was always polarizing, some loved it, some hated it. I will point out though, that it predates type hints and it was an effective way to declare classes with little "syntax noise" which made it easy to write but also easy to read, because you used the import name as part of the APIs. Here is more context: https://www.attrs.org/en/stable/names.html https://www.attrs.org/en/stable/names.html I REGRET NOTHING
    - ericvsmith 1y ago
      For what it’s worth, I was in the “loved it” camp. (I’m the author of dataclasses, and I owe an immeasurable debt to Hynek).
      - sspies 1y ago
        Thank you for creating dataclasses!
    - g958198 1y ago
      if it's good enough for glyph, it's good enough for me
- skydhash 1y ago
  DDD is nice especially in the first phase. All the concepts are actually rehashed from earlier principles. There’s nothing fully new there.
- switchbak 1y ago
  I’d call out patternitis and over-OOPification way before I’d criticize DDD. Yes, the latter can go too far, but the two former cases are abused on a much more frequent basis. Happily the pattern crazyness has died down a lot though.
g958198 1y ago
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.
deleted 1y ago
[deleted]
loevborg 1y ago
Great talk, there's a lot I can relate to in here. I find this topic difficult to navigate because of the many trade-offs. One aspect that wasn't mentioned is temporal. A lot of the time, it makes sense to start with a "database-oriented design" (in the pejorative sense), where your types are just whatever shape your data has in Postgres. However, as time goes on and your understanding of the domain grows, you start to realize the limitations of that approach. At that point, it probably makes sense to introduce a separate domain model and use explicit mapping. But finding that point in time where you want to switch is not trivial. Should you start with a domain model from the get-go? Maybe, but it's risky because you may end up with domain objects that don't actually do a better job of representing the domain than whatever you have in your SQL tables. It also feels awkward (and is hard to justify in a team) to map back and forth between domain model, sql SELECT row and JSON response body if they're pretty much the same, at least initially. So it might very well be that, rather than starting with a domain model, the best approach is to refactor your way into it once you have a better feel for the domain. Err on the side of little or no abstraction, but don't hesitate to introduce abstraction when you feel the pain from too much "concretion". Again, it takes judgment so it's hard to teach (which the talk does an admirable job in pointing out).
- bubblyworld 1y ago
  Pretty naive question, but what differentiates a "domain model" from these more primitive data representations? I see the term thrown around a lot but I've never been able to grok what people actually mean. By domain model do you mean something like what a scientist would call a theory? A description of your domain in terms of some fundamental concepts, how they relate to each other, their behaviour, etc? Something like a specification? Which could of course have many possible concrete implementations (and many possible ways to represent it with data). Where I get confused with this is I'm not sure what it means to map data to and from your domain model (it's an actual code entity?), so I'm probably thinking about this wrong.
  - metayrnc 1y ago
    For me domain model means capturing as much information about the domain you are modeling in the types and data structures you use. Most of the time that ends up meaning use Unions to make illegal states unrepresentable. For example, I have not seen a database native approach to saving union types to databases. In that case using another domain layer becomes mandatory. For context: https://fsharpforfunandprofit.com/posts/designing-with-types-making-illegal-states-unrepresentable/ https://fsharpforfunandprofit.com/posts/designing-with-types...
Noumenon72 1y ago
There was a comment on here saying this was an implied diss of SQLModel, but now that I came back to reply to it it's gone. Weird. Since it's implied I couldn't find it in the slides.
- davepeck 1y ago
  I wrote and then quickly deleted that comment; I never want to speak negatively publicly about open source projects — projects that people work incredibly hard to build and maintain. I felt my original comment crossed that line. In any case, there is a slide in the talk that has both the Pydantic and SQL Alchemy logos. As far as I know, there’s only one (somewhat popular) library that ties these two together. I think the speaker makes a persuasive case that data, domain, API, and other models should remain related but distinct.
  - Noumenon72 1y ago
    Thanks for explaining where it went and where to find it. I am only writing glue code without a domain model so I haven't seen the problems yet.
vinipolicena 1y ago
Parts of the talk remind me of https://www.amundsens-maxim.com/ https://www.amundsens-maxim.com/
- hynek 1y ago
  ha, I wish I saw that while working on that talk! adding it to the resources!
knallfrosch 1y ago
I had the reverse problem a month ago. Greenfield project without existing data, domain model or API. I had no reason to model the API or persistence layer any different than the domain model, so I implemented the same class 3 times, with 2 mappings on top. For what? Well at some point, you will have API consumers and existing data and you need to be able to change the then-existing system.
leecommamichael 1y ago
Interesting, perhaps modern conveniences encourage coupling. No wonder there are so many single-monitor, no-LSP savants out there.
HappMacDonald 1y ago
There are certainly times I would love to see a presentation like this reformatted as an article. I tried pulling out the Youtube transcript, but it was very uncomfortable to read with asides and jokes and "ums" that are all native artifacts of speaking in front of a crowd but that only represent noise in when converted to long written form.
- hynek 1y ago
  Shouldn't some AI be able to clean that up for you? This seems something LLMs should be well-suited for. --- FWIW, I'm the speaker and let me be honest with you: I'm super unmotivated to write nowadays. In the past, my usual MO was writing a bunch of blog posts and submit the ones that resonated to CfPs (e.g. <https://hynek.me/articles/python-subclassing-redux/ https://hynek.me/articles/python-subclassing-redux/> → <https://hynek.me/talks/subclassing/ https://hynek.me/talks/subclassing/>). However, nowadays thanks to the recent-ish changes in Twitter and Google, my only chance to have my stuff read by a nontrivial amount of people is hitting HN frontage which is a lottery. It's so bad I even got into YouTubing to get a roll at the algorithm wheel. It takes (me) a lot of work to crystallize and compress my thoughts like this. Giving it as a talk at a big conference, at least opens the door to interesting IRL interactions which are important (to me), because I'm an introvert. I can't stress enough how we're currently eating the seed corn by killing the public web.
- moozilla 1y ago
  Here's an attempt at cleaning it up with Gemini 2.5 Pro: https://rentry.org/nyznvoy5 https://rentry.org/nyznvoy5 I just pasted the YouTube link into AI Studio and gave it this prompt if you want to replicate: reformat this talk as an article. remove ums/ahs, but do not summarize, the context should be substantively the same. include content from the slides as well if possible.
  - Noumenon72 1y ago
    Thanks, saved me so much time
  - hynek 1y ago
fadfsdfaes 1y ago
[flagged]
sfdoiaojfias 1y ago
[flagged]

212 points by NeutralForest 1y ago

1317 1y ago

[video]

I'm not sure I'd take design advice from someone who thought attr.ib and attr.s were a good idea. On the other hand he points out that DDD is a vacuous cult, which is true.

wilkystyle 1y ago
> I'm not sure I'd take design advice from someone who thought attr.ib and attr.s were a good idea Can you elaborate?
- hynek 1y ago
  that's a reference to my attrs library which is what data classes are based on. It originally used @attr.s class C: x = attr.ib() as its main api (with `attr.attrs` and `attr.attrib` as serious business aliases so you didn't have to use it). That API was always polarizing, some loved it, some hated it. I will point out though, that it predates type hints and it was an effective way to declare classes with little "syntax noise" which made it easy to write but also easy to read, because you used the import name as part of the APIs. Here is more context: https://www.attrs.org/en/stable/names.html https://www.attrs.org/en/stable/names.html I REGRET NOTHING
  - ericvsmith 1y ago
    For what it’s worth, I was in the “loved it” camp. (I’m the author of dataclasses, and I owe an immeasurable debt to Hynek).
    - sspies 1y ago
      Thank you for creating dataclasses!
  - g958198 1y ago
    if it's good enough for glyph, it's good enough for me
skydhash 1y ago
DDD is nice especially in the first phase. All the concepts are actually rehashed from earlier principles. There’s nothing fully new there.
switchbak 1y ago
I’d call out patternitis and over-OOPification way before I’d criticize DDD. Yes, the latter can go too far, but the two former cases are abused on a much more frequent basis. Happily the pattern crazyness has died down a lot though.

g958198 1y ago

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.

deleted 1y ago

[deleted]

loevborg 1y ago

Great talk, there's a lot I can relate to in here. I find this topic difficult to navigate because of the many trade-offs. One aspect that wasn't mentioned is temporal. A lot of the time, it makes sense to start with a "database-oriented design" (in the pejorative sense), where your types are just whatever shape your data has in Postgres. However, as time goes on and your understanding of the domain grows, you start to realize the limitations of that approach. At that point, it probably makes sense to introduce a separate domain model and use explicit mapping. But finding that point in time where you want to switch is not trivial. Should you start with a domain model from the get-go? Maybe, but it's risky because you may end up with domain objects that don't actually do a better job of representing the domain than whatever you have in your SQL tables. It also feels awkward (and is hard to justify in a team) to map back and forth between domain model, sql SELECT row and JSON response body if they're pretty much the same, at least initially. So it might very well be that, rather than starting with a domain model, the best approach is to refactor your way into it once you have a better feel for the domain. Err on the side of little or no abstraction, but don't hesitate to introduce abstraction when you feel the pain from too much "concretion". Again, it takes judgment so it's hard to teach (which the talk does an admirable job in pointing out).

bubblyworld 1y ago
Pretty naive question, but what differentiates a "domain model" from these more primitive data representations? I see the term thrown around a lot but I've never been able to grok what people actually mean. By domain model do you mean something like what a scientist would call a theory? A description of your domain in terms of some fundamental concepts, how they relate to each other, their behaviour, etc? Something like a specification? Which could of course have many possible concrete implementations (and many possible ways to represent it with data). Where I get confused with this is I'm not sure what it means to map data to and from your domain model (it's an actual code entity?), so I'm probably thinking about this wrong.
- metayrnc 1y ago
  For me domain model means capturing as much information about the domain you are modeling in the types and data structures you use. Most of the time that ends up meaning use Unions to make illegal states unrepresentable. For example, I have not seen a database native approach to saving union types to databases. In that case using another domain layer becomes mandatory. For context: https://fsharpforfunandprofit.com/posts/designing-with-types-making-illegal-states-unrepresentable/ https://fsharpforfunandprofit.com/posts/designing-with-types...

Noumenon72 1y ago

There was a comment on here saying this was an implied diss of SQLModel, but now that I came back to reply to it it's gone. Weird. Since it's implied I couldn't find it in the slides.

davepeck 1y ago
I wrote and then quickly deleted that comment; I never want to speak negatively publicly about open source projects — projects that people work incredibly hard to build and maintain. I felt my original comment crossed that line. In any case, there is a slide in the talk that has both the Pydantic and SQL Alchemy logos. As far as I know, there’s only one (somewhat popular) library that ties these two together. I think the speaker makes a persuasive case that data, domain, API, and other models should remain related but distinct.
- Noumenon72 1y ago
  Thanks for explaining where it went and where to find it. I am only writing glue code without a domain model so I haven't seen the problems yet.

vinipolicena 1y ago

Parts of the talk remind me of https://www.amundsens-maxim.com/ https://www.amundsens-maxim.com/

hynek 1y ago
ha, I wish I saw that while working on that talk! adding it to the resources!

knallfrosch 1y ago

I had the reverse problem a month ago. Greenfield project without existing data, domain model or API. I had no reason to model the API or persistence layer any different than the domain model, so I implemented the same class 3 times, with 2 mappings on top. For what? Well at some point, you will have API consumers and existing data and you need to be able to change the then-existing system.

leecommamichael 1y ago

Interesting, perhaps modern conveniences encourage coupling. No wonder there are so many single-monitor, no-LSP savants out there.

HappMacDonald 1y ago

There are certainly times I would love to see a presentation like this reformatted as an article. I tried pulling out the Youtube transcript, but it was very uncomfortable to read with asides and jokes and "ums" that are all native artifacts of speaking in front of a crowd but that only represent noise in when converted to long written form.

hynek 1y ago
Shouldn't some AI be able to clean that up for you? This seems something LLMs should be well-suited for. --- FWIW, I'm the speaker and let me be honest with you: I'm super unmotivated to write nowadays. In the past, my usual MO was writing a bunch of blog posts and submit the ones that resonated to CfPs (e.g. <https://hynek.me/articles/python-subclassing-redux/ https://hynek.me/articles/python-subclassing-redux/> → <https://hynek.me/talks/subclassing/ https://hynek.me/talks/subclassing/>). However, nowadays thanks to the recent-ish changes in Twitter and Google, my only chance to have my stuff read by a nontrivial amount of people is hitting HN frontage which is a lottery. It's so bad I even got into YouTubing to get a roll at the algorithm wheel. It takes (me) a lot of work to crystallize and compress my thoughts like this. Giving it as a talk at a big conference, at least opens the door to interesting IRL interactions which are important (to me), because I'm an introvert. I can't stress enough how we're currently eating the seed corn by killing the public web.
moozilla 1y ago
Here's an attempt at cleaning it up with Gemini 2.5 Pro: https://rentry.org/nyznvoy5 https://rentry.org/nyznvoy5 I just pasted the YouTube link into AI Studio and gave it this prompt if you want to replicate: reformat this talk as an article. remove ums/ahs, but do not summarize, the context should be substantively the same. include content from the slides as well if possible.
- Noumenon72 1y ago
  Thanks, saved me so much time
- hynek 1y ago

fadfsdfaes 1y ago

[flagged]

sfdoiaojfias 1y ago

[flagged]