3 ms·

I have been thinking along those lines for a while. I didn't take it quite from the same angle but it boils down to the same idea. For me, each layer of abstra

by d--b 3y ago

I have been thinking along those lines for a while. I didn't take it quite from the same angle but it boils down to the same idea. For me, each layer of abstraction should roughly correspond to people's roles. In my line of work (finance) it's a little more complicated than what the article states. There are people who specialize in deep computational optimization. There are people who do micro financial models There are people who do macro financial models There are people who do user interfaces There are people who do the piping between all these The ideal to aim for is that each layer of abstraction is cut around those fairly well defined roles. Each person should be able to own their piece of the codebase and hopefully manipulate objects/languages of the right level for them. In the dishwasher example, the middle layer should be cut in the "electronics layer" and the "hydrolics layer", the electronics layer interfaces with both the user and the hydrolics layer, but the hydrolics layer never interfaces with the user. And it's easy to see that the electronics and the hydrolics are not designed by the same person. It's a way of framing things that makes sense for me.

Jtsummers 3y ago
https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law Conway's Law is an observation that what you describe is what often happens anyways. Organizational structure influences system design and structure.
- rollinDyno 3y ago
  I find it interesting that as our societies have become increasingly complex and we have organically implemented what we think is an efficient division of labor, we have ended up with people not only specializing across multiple sectors, but also in different layers of abstraction within the same sector. We have done all of this without even realizing that we were pushing people towards a different interface of the problem, but the same problem nonetheless.
  - zharknado 3y ago
    Not sure I can prove it, but my intuition is that this actually flows in the opposite direction, i.e. we organically discover efficient organizational buckets and then ascribe boundaries and labels to those clusterings. I.e. the interface isn’t an objective fact, it’s a normative way of framing a boundary.
- d--b 3y ago
  Thanks I didn't know that one!
spacebacon 3y ago
The three in this case to me is information architecture, user experience, and user interface. There are many sets of three. Each observer jockey's their own perspective.
- Terr_ 3y ago
  "Upstream, Me, and Downstream." Everybody can use those groups to arrange the universe, but there will be widespread disagreement over who belongs in what category. :P
dredmorbius 3y ago
I think you can reduce (abstract?) the number of role further: - Builders. This would be software developers in the I.T. world. - Users. Regardless of what their specific domain expertise (or lack) is in, those who utilise the system. - Maintainers. Those who fix what's broken. "Repair techs" from the world of complex machinery, "software maintenance" in I.T. Possibly also: sales & marketing, who describe and position the products, management, who oversee general operations, and logistics and/or operations, who fit the pieces together and support them outside general maintenance (an I.T. analogue might be DevOps or systems admins roles). Each of these has their own perspective, goals, relationship, and set of concerns with the system. And whilst there may well be levels of expertise within each role, there's a larger set of uniform and consistent concerns and relationships each addresses as well. In complex physical kit, you'll generally see such roles expressed as engineering, manufacturing, marketing, (customer) operators, logistics, maintenance (on-site repair and adjustments), and sales & marketing, or terms to that effect. The roles typically exist within software and information products as well, though of course not all physical analogues map directly. Within a complex product, you'll have the user interface, a maintenance or technician's interface, component-level design (which may or may not be designed for field maintenance), demo modes and marketing collateral (for sales/marketing), and considerations for the actual construction, packaging, and logistics supply- and delivery-chain support for the devices, etc. Each of these is effectively a level of abstraction onto the end product.

by d--b 3y ago

Jtsummers 3y ago

https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law Conway's Law is an observation that what you describe is what often happens anyways. Organizational structure influences system design and structure.

rollinDyno 3y ago
I find it interesting that as our societies have become increasingly complex and we have organically implemented what we think is an efficient division of labor, we have ended up with people not only specializing across multiple sectors, but also in different layers of abstraction within the same sector. We have done all of this without even realizing that we were pushing people towards a different interface of the problem, but the same problem nonetheless.
- zharknado 3y ago
  Not sure I can prove it, but my intuition is that this actually flows in the opposite direction, i.e. we organically discover efficient organizational buckets and then ascribe boundaries and labels to those clusterings. I.e. the interface isn’t an objective fact, it’s a normative way of framing a boundary.
d--b 3y ago
Thanks I didn't know that one!

spacebacon 3y ago

The three in this case to me is information architecture, user experience, and user interface. There are many sets of three. Each observer jockey's their own perspective.

Terr_ 3y ago
"Upstream, Me, and Downstream." Everybody can use those groups to arrange the universe, but there will be widespread disagreement over who belongs in what category. :P

dredmorbius 3y ago

I think you can reduce (abstract?) the number of role further: - Builders. This would be software developers in the I.T. world. - Users. Regardless of what their specific domain expertise (or lack) is in, those who utilise the system. - Maintainers. Those who fix what's broken. "Repair techs" from the world of complex machinery, "software maintenance" in I.T. Possibly also: sales & marketing, who describe and position the products, management, who oversee general operations, and logistics and/or operations, who fit the pieces together and support them outside general maintenance (an I.T. analogue might be DevOps or systems admins roles). Each of these has their own perspective, goals, relationship, and set of concerns with the system. And whilst there may well be levels of expertise within each role, there's a larger set of uniform and consistent concerns and relationships each addresses as well. In complex physical kit, you'll generally see such roles expressed as engineering, manufacturing, marketing, (customer) operators, logistics, maintenance (on-site repair and adjustments), and sales & marketing, or terms to that effect. The roles typically exist within software and information products as well, though of course not all physical analogues map directly. Within a complex product, you'll have the user interface, a maintenance or technician's interface, component-level design (which may or may not be designed for field maintenance), demo modes and marketing collateral (for sales/marketing), and considerations for the actual construction, packaging, and logistics supply- and delivery-chain support for the devices, etc. Each of these is effectively a level of abstraction onto the end product.