3 ms·

The examples are great but .. I think.. the conclusion is naiive/wrong in a lot of cases. Aren't both right and left sides of most examples fundamentally diffe

by geokon 1y ago

The examples are great but .. I think.. the conclusion is naiive/wrong in a lot of cases. Aren't both right and left sides of most examples fundamentally different views of the same exact underlying data/relationships? If you're locked in to one view, then your code sucks. I'm not an expert in this stuff, but I think this is just a natural consequence of thinking in terms of tables and SQL. If you think in terms of triple stores and graph databases then you can derive either a left side or right side view as needed and you can operate on either abstraction

athrowaway3z 1y ago
The data might be a graph, but we're interested in conceptual units of data / abstraction. Organizations as a whole need to talk the same language. "We have the data somewhere, somehow - so figure it out" doesn't work when communicating. A good proxy measurement is how fast it takes two random employees to talk about the same thing. It's the effective knowledge transfer speed after taking into account the data density / compression. The infinite many views of a graph don't compress. Or more practically, any graph will continuously evolve a set of 'common views' that an organization understands and uses.
- geokon 1y ago
  I think you're mixing things up. People don't need to have the same language at all. Compression can happen by "users" at a higher level when interacting with the data model. The data model itself does not need to encode this. HR may want to look at employees from one view and your accountant might want to look from an entirely different one. They communicate with people in their own field using their own compression. You don't need to settle on one abstraction for everyone. The data-model designers need to communicate with each other.. sure.. but it's their job to think in a non-compressed way about the data model.
  - prmph 1y ago
    Data model here is not necessarily what is in the DB, I think TFA is using "data model" more abstractly, is the model of the business domain that is prevalent in the organization and structures how they talk about the domain.
    - geokon 1y ago
      An interesting take. In the abstract it probably makes sense. You can't make a large org like Instagram start doing a Twitter or something like that.. Though I read the subtext to be talking about code > By the time the architecture solidifies around these implicit choices, it’s nearly impossible to change. > Incumbents couldn’t match this without rebuilding from scratch. My point is that if your actual code-level datamodel is flexible then you often architecturally can pivot to a different view (the Rippling example). My guess as to why HipChat can't change to a Slack model is because they "coded it wrong". It's not somehow inherently orthogonal. The essay present the models are a fait accompli when in fact, if you step back they're for the most part just views on the same fundamental data/relationships - and if modeled correctly I don't see any reason why you wouldn't be able to change between views. The central thesis that "Your data model is your destiny" does not have to be true Though that said, there are some examples that probably can't pivot due to some inherent design limitation (ex: the Adobe case)

by geokon 1y ago

athrowaway3z 1y ago

The data might be a graph, but we're interested in conceptual units of data / abstraction. Organizations as a whole need to talk the same language. "We have the data somewhere, somehow - so figure it out" doesn't work when communicating. A good proxy measurement is how fast it takes two random employees to talk about the same thing. It's the effective knowledge transfer speed after taking into account the data density / compression. The infinite many views of a graph don't compress. Or more practically, any graph will continuously evolve a set of 'common views' that an organization understands and uses.

geokon 1y ago
I think you're mixing things up. People don't need to have the same language at all. Compression can happen by "users" at a higher level when interacting with the data model. The data model itself does not need to encode this. HR may want to look at employees from one view and your accountant might want to look from an entirely different one. They communicate with people in their own field using their own compression. You don't need to settle on one abstraction for everyone. The data-model designers need to communicate with each other.. sure.. but it's their job to think in a non-compressed way about the data model.
- prmph 1y ago
  Data model here is not necessarily what is in the DB, I think TFA is using "data model" more abstractly, is the model of the business domain that is prevalent in the organization and structures how they talk about the domain.
  - geokon 1y ago
    An interesting take. In the abstract it probably makes sense. You can't make a large org like Instagram start doing a Twitter or something like that.. Though I read the subtext to be talking about code > By the time the architecture solidifies around these implicit choices, it’s nearly impossible to change. > Incumbents couldn’t match this without rebuilding from scratch. My point is that if your actual code-level datamodel is flexible then you often architecturally can pivot to a different view (the Rippling example). My guess as to why HipChat can't change to a Slack model is because they "coded it wrong". It's not somehow inherently orthogonal. The essay present the models are a fait accompli when in fact, if you step back they're for the most part just views on the same fundamental data/relationships - and if modeled correctly I don't see any reason why you wouldn't be able to change between views. The central thesis that "Your data model is your destiny" does not have to be true Though that said, there are some examples that probably can't pivot due to some inherent design limitation (ex: the Adobe case)