4 ms·

"(e.g. database normalization) while also considering things like cache lines and latency between networked participants is how the magic is done." I wouldn't

"(e.g. database normalization) while also considering things like cache lines and latency between networked participants is how the magic is done." I wouldn't put abstract domain modeling or database normalization alongside a first principles back-of-the-envelope approach. Abstract academic terms are certainly useful insofar as they provide a shared language to discuss systems and discover research, but... it really does actually seem to be the first principles things, the physical facts, like cache lines and latency ("practical engineering constraint solving" as you put it well) that drive the best designs, and far ahead of things like database normalization. This is also the approach taken by Data-oriented Design [1], which is more similar I think, than the abstract domain modeling approach. In fact, abstractions and domain modeling principles can often lead one away from the ground reality of the machine, or "mechanical sympathy". [1] https://en.wikipedia.org/wiki/Data-oriented_design https://en.wikipedia.org/wiki/Data-oriented_design

dragonwriter 5y ago
> Abstract academic terms are certainly useful insofar as they provide a shared language to discuss systems and discover research, but... it really does actually seem to be the "first principles" things like cache lines and latency ("practical engineering constraint solving") that drive the best designs, and far ahead of things like "database normalization". Database normalization is a tool to deal with correctness (avoiding data anomalirs) and flexibility, cache lines and latency deal with performance. Fast but wrong and/or brittle designs are no more “best” in general than correct and flexible but poorly-performing ones; though the exact balance between those two things differs between applications.
- jorangreef 5y ago
  Sure, and I'm not saying that something like database normalization is not useful. I just don't think that the "Habits of Expert Software Designers" like Jeff Dean or Martin Thompson are to be found in how they would design normalized SQL schemas when asked [1]. Rather, it's in how they would build things like LSM-Trees or Replicated State Machines. And I think if one looks at that design process, one would find that they reach for back-of-the-envelope calculations far more often than most other tools. They appear to take a first principles approach. Again, that doesn't mean that database normalization is not a useful tool. I just wouldn't put any kind of abstract modeling approach alongside a first principles approach when it comes to systems design. [1] Regarding normalized SQL schemas, I wouldn't be surprised if people like Jeff Dean or Martin Thompson went denormalized where it made more sense, or eschewed database indexes in favor of learned indexes, to optimize not only for performance but also for cost or time to recovery etc.
  - bob1029 5y ago
    SQL is just one tool/representation. I would focus more on the idea of "managing complexity" more than any specific technological implementation of this idea. This gets me back to Excel. Really hard to get opinionated about a computerized spreadsheet representation.
bob1029 5y ago
> Abstract academic terms are certainly useful insofar as they provide a shared language to discuss systems and discover research, but... it really does actually seem to be the first principles things, the physical facts, like cache lines and latency ("practical engineering constraint solving" as you put it well) that drive the best designs, and far ahead of things like database normalization. If you have a problem domain that deals with thousands (or more) of types/facts/relations, you will quickly find that starting with code and how tightly you can pack your data in memory to be a massive mistake. The computer is arguably the most important stakeholder in all of this design work, but it is not the only critical one for most businesses. Being able to express a complex state machine to a domain expert who doesn't know what visual studio looks like is the biggest challenge I run into in the real world. "Correct" is more important than "fast" every single day of the week where I work.
- jorangreef 5y ago
  "If you have a problem domain that deals with thousands (or more) of types/facts/relations, you will quickly find that starting with code and how tightly you can pack your data in memory to be a massive mistake." To be fair, this depends entirely on the business requirements of the software being designed. For example, a safety critical airbag deploy mechanism may need to make hard real time decisions so that memory layout (let alone dynamic allocation) is anything but "a massive mistake", or a file system may need to account for the spatial locality of corruption by writing superblock headers to different locations on disk. I was also thinking of software design, not business applications that can be solved with SQL, and specifically in the context of infrastructure systems designed by experts such as Jeff Dean or Martin Thompson.

dragonwriter 5y ago

> Abstract academic terms are certainly useful insofar as they provide a shared language to discuss systems and discover research, but... it really does actually seem to be the "first principles" things like cache lines and latency ("practical engineering constraint solving") that drive the best designs, and far ahead of things like "database normalization". Database normalization is a tool to deal with correctness (avoiding data anomalirs) and flexibility, cache lines and latency deal with performance. Fast but wrong and/or brittle designs are no more “best” in general than correct and flexible but poorly-performing ones; though the exact balance between those two things differs between applications.

jorangreef 5y ago
Sure, and I'm not saying that something like database normalization is not useful. I just don't think that the "Habits of Expert Software Designers" like Jeff Dean or Martin Thompson are to be found in how they would design normalized SQL schemas when asked [1]. Rather, it's in how they would build things like LSM-Trees or Replicated State Machines. And I think if one looks at that design process, one would find that they reach for back-of-the-envelope calculations far more often than most other tools. They appear to take a first principles approach. Again, that doesn't mean that database normalization is not a useful tool. I just wouldn't put any kind of abstract modeling approach alongside a first principles approach when it comes to systems design. [1] Regarding normalized SQL schemas, I wouldn't be surprised if people like Jeff Dean or Martin Thompson went denormalized where it made more sense, or eschewed database indexes in favor of learned indexes, to optimize not only for performance but also for cost or time to recovery etc.
- bob1029 5y ago
  SQL is just one tool/representation. I would focus more on the idea of "managing complexity" more than any specific technological implementation of this idea. This gets me back to Excel. Really hard to get opinionated about a computerized spreadsheet representation.

bob1029 5y ago

> Abstract academic terms are certainly useful insofar as they provide a shared language to discuss systems and discover research, but... it really does actually seem to be the first principles things, the physical facts, like cache lines and latency ("practical engineering constraint solving" as you put it well) that drive the best designs, and far ahead of things like database normalization. If you have a problem domain that deals with thousands (or more) of types/facts/relations, you will quickly find that starting with code and how tightly you can pack your data in memory to be a massive mistake. The computer is arguably the most important stakeholder in all of this design work, but it is not the only critical one for most businesses. Being able to express a complex state machine to a domain expert who doesn't know what visual studio looks like is the biggest challenge I run into in the real world. "Correct" is more important than "fast" every single day of the week where I work.

jorangreef 5y ago
"If you have a problem domain that deals with thousands (or more) of types/facts/relations, you will quickly find that starting with code and how tightly you can pack your data in memory to be a massive mistake." To be fair, this depends entirely on the business requirements of the software being designed. For example, a safety critical airbag deploy mechanism may need to make hard real time decisions so that memory layout (let alone dynamic allocation) is anything but "a massive mistake", or a file system may need to account for the spatial locality of corruption by writing superblock headers to different locations on disk. I was also thinking of software design, not business applications that can be solved with SQL, and specifically in the context of infrastructure systems designed by experts such as Jeff Dean or Martin Thompson.