6 ms·

This post is not wrong, but it fails to distinguish between high-level product decisions and high-level engineering implementation decisions. They are too side

This post is not wrong, but it fails to distinguish between high-level product decisions and high-level engineering implementation decisions. They are too sides of the same coin, to be sure, but there is an incredibly common failure mode where product and engineering "agree" on a high-level direction, but each is holding different assumptions in their head about what that means. That's why framing like: > The mistake of focusing on concrete details is incredibly dangerous. Engineers love to think about abstractions, and leaders managing a lot of people are all too eager to buy into the promise of magic abstractions that align everyone and produce optimal results with the army of worker bees figuring out all the details of the perfect vision created by the god-like leaders. The only problem is that the devil is in the details. Always. The only way you can make a good decision at the top of the tree, is by being an incredibly seasoned expert that has a strong intuition about how the details are going to play out on the leaf nodes. You need this on both the engineering and the product side. And even then, you will always discover things once you start building, and if you care about a quality product you will have to back things out. The only defense against this is relentless focus on simplicity, which tends be a viable option (in the consumer space at least) because at the end of the day, your users have finite attention spans and do not want to have to deal with anything too complicated.

peteradio 3y ago
I wonder if domain specific templates/views could be made to help bridge the gap between the leafs (layouts, colors etc) to the base constraints (performance, security etc). Engineers wind up acting like compilers for the product owners ideas and sometimes that shit don't compile and it can be pretty tough to explain why not.
- crq-yml 3y ago
  The leaf elements are often coupled by a protocol, even if it's as simple as "call this API to return a result". Domain language is derived from seeing that a certain conventional protocol is used over and over. So to me, protocol is the focus of modularity, because it lets you talk within the domain. However, protocol isn't addressed by generalizing it: that just means you have added a container for the meaningful part of the content. Something that comes up when working in a point-free style, as in Forth or APL, is that protocol is shoved in your face immediately because the sequence of arguments now matters, and that has downsides(stack underflow errors?) but also upsides (conciseness, ease of factoring). When I reach for that, it tends to mean that I intend to find a tighter specification for the domain.
vmfunction 3y ago
> The only problem is that the devil is in the details. Always. The only way you can make a good decision at the top of the tree, is by being an incredibly seasoned expert that has a strong intuition about how the details are going to play out on the leaf nodes. You got that right. Being developing over a decade for different kind of companies. "the devil is always in the details" However it is below that gets in the way: > is incredibly dangerous. Engineers love to think about abstractions, and leaders managing a lot of people are all too eager to buy into the promise of magic abstractions that align everyone and produce optimal results with the army of worker bees figuring out all the details of the perfect vision created by the god-like leaders.

peteradio 3y ago

I wonder if domain specific templates/views could be made to help bridge the gap between the leafs (layouts, colors etc) to the base constraints (performance, security etc). Engineers wind up acting like compilers for the product owners ideas and sometimes that shit don't compile and it can be pretty tough to explain why not.

crq-yml 3y ago
The leaf elements are often coupled by a protocol, even if it's as simple as "call this API to return a result". Domain language is derived from seeing that a certain conventional protocol is used over and over. So to me, protocol is the focus of modularity, because it lets you talk within the domain. However, protocol isn't addressed by generalizing it: that just means you have added a container for the meaningful part of the content. Something that comes up when working in a point-free style, as in Forth or APL, is that protocol is shoved in your face immediately because the sequence of arguments now matters, and that has downsides(stack underflow errors?) but also upsides (conciseness, ease of factoring). When I reach for that, it tends to mean that I intend to find a tighter specification for the domain.

vmfunction 3y ago

> The only problem is that the devil is in the details. Always. The only way you can make a good decision at the top of the tree, is by being an incredibly seasoned expert that has a strong intuition about how the details are going to play out on the leaf nodes. You got that right. Being developing over a decade for different kind of companies. "the devil is always in the details" However it is below that gets in the way: > is incredibly dangerous. Engineers love to think about abstractions, and leaders managing a lot of people are all too eager to buy into the promise of magic abstractions that align everyone and produce optimal results with the army of worker bees figuring out all the details of the perfect vision created by the god-like leaders.