3 ms·

This sounds like an application risk-aversion/-seeking that Kahneman highlights in "Thinking, Fast and Slow" Specifically... each of these individual decisions

This sounds like an application risk-aversion/-seeking that Kahneman highlights in "Thinking, Fast and Slow" Specifically... each of these individual decisions (wrt to abstraction, in this context) was made to locally optimize (speed, simplicity, etc) some issue or other But when taken in gestalt, they're overall not only not optimal, but downright bad Most of those decisions are made by people far to close to a tiny portion of the problem to understand the implications of their choices Alternatively, it's an application of the blind mice finding an elephant story: yes, it's like a rope, a fan, a tree, a hose, and on and on But it's none of those, it's an elephant

projektfu 4y ago
The title needs work too. People will undoubtedly assume that reducing abstraction will make things cheaper.
- sghio4Q2 4y ago
  Indeed.
- cryptonector 4y ago
  Eh, some people might do that, but, really, titles like that beg you to read the article (or at least it's why I read it). The article absolutely does not say anything like "reducing abstraction will make things cheaper".
- danShumway 4y ago
  Sometimes reducing abstractions will make things cheaper. Some regular traps that I see people run into with abstractions: - building around scenarios that they can be pretty confident that they will never need to handle. - building abstractions that are larger and more complicated than the thing they are abstracting (this tends to happen when people build abstractions of abstractions). - building abstractions before they have a proper understanding of what they're abstracting and what they'll need to encapsulate. In many of those cases, reducing abstractions (even just temporarily) reduces complexity. When I'm building purely personal projects, I don't use abstractions to help me deal with directory structure on Windows, because I don't use Windows, and that would be additional complexity for no benefit -- so it's simpler for me to just work with the lower level OS paths. When I start writing an abstraction I look at the amount of documentation I'm generating, and if I'm generating more documentation than it would take to explain the underlying system, I look to see if there are concepts that I can remove. I worked at a company where our build process became considerably simpler when we stopped using high-level build tools like Gulp/Grunt and switched to writing simple Node scripts, because it was easier to debug what those scripts were doing. We simplified that process even further by occasionally just dipping into Bash scripts. Working with low-level concepts for a while often also gives you better understanding of what you need to abstract. I've worked with codebases where the abstractions all get built first, and it's not uncommon for those abstractions to be built around tasks that are pretty simple and easy to do with lower-level code, at the same time that the abstractions completely ignore the really difficult tasks that are very annoying to do. And once abstractions get baked in, it was time consuming and difficult and expensive to pull them out and rewrite them. Going back to the scripts above, our build process got better because we made it simple to begin with -- a set of scripts, rather than a large established pipeline -- and then as we identified pain points, we started abstracting those pain points away. That allowed us to not waste time rewriting abstractions over and over and instead to have targeted small interfaces that helped us with the actual painful parts of building and deployment. It is surprisingly common for software to be over-abstracted to the point where it is more complicated to deal with than it would be otherwise. I mean, heck, this comes up in web development all the time, it is one of the primary criticisms people have of the JS ecosystem -- that it overcomplicates development. In many cases those complications exist for reasons, they solve real problems that people have had. But also in many cases, someone's individual blog doesn't need any of that, and it would be cheaper and easier for them to build something smaller and simpler. If I can build a site that is one HTML file and one CSS file, and I know that's all I'm going to need, then it's overkill to try and set up a bunch of abstractions on top of that.
hinkley 4y ago
You’re speaking to impedance mismatch which is one of the classic blunders. Systems that don’t use the same jargon as the user base end up having substantial bugs, especially ones the authors insist are features. The abstractions are a bad fit for the problem domain and they break things. I’m in a project that did that massively, at the hands of both architectural astronauts and another common blunder: people who seemed to think the concerns of the user base are beneath them tend to create a fantasy world for themselves where they can pretend they work on something more esoteric than the petty concerns of the people who pay their salaries. Because of the bullshit (and more importantly, the top-heavy sources of that bullshit) we’ve lost a lot of the better people who could have fixed that situation. Meanwhile we are also trying to expand into a new industry, and I can’t help but wonder if we would have been in trouble even if our abstractions had matched our core competency. I would have needed all of those missing people to make the refactors necessary to do that work, so the agents of chaos and delusion are a little vindicated. I have a couple of things I want to button up but they are all fast approaching. I don’t expect to be here in six months. I’ve started fantasizing about my exit interview. In which I will probably suggest that my team is too powerful and isolated from the end user and so needs to be disbanded, its members dispersed into groups one and two steps closer to the users. So as to concretize some of the code and confront them with the day to day struggles of internal customers, dealing with the batshit parts of the code.

projektfu 4y ago

The title needs work too. People will undoubtedly assume that reducing abstraction will make things cheaper.

sghio4Q2 4y ago
Indeed.
cryptonector 4y ago
Eh, some people might do that, but, really, titles like that beg you to read the article (or at least it's why I read it). The article absolutely does not say anything like "reducing abstraction will make things cheaper".
danShumway 4y ago
Sometimes reducing abstractions will make things cheaper. Some regular traps that I see people run into with abstractions: - building around scenarios that they can be pretty confident that they will never need to handle. - building abstractions that are larger and more complicated than the thing they are abstracting (this tends to happen when people build abstractions of abstractions). - building abstractions before they have a proper understanding of what they're abstracting and what they'll need to encapsulate. In many of those cases, reducing abstractions (even just temporarily) reduces complexity. When I'm building purely personal projects, I don't use abstractions to help me deal with directory structure on Windows, because I don't use Windows, and that would be additional complexity for no benefit -- so it's simpler for me to just work with the lower level OS paths. When I start writing an abstraction I look at the amount of documentation I'm generating, and if I'm generating more documentation than it would take to explain the underlying system, I look to see if there are concepts that I can remove. I worked at a company where our build process became considerably simpler when we stopped using high-level build tools like Gulp/Grunt and switched to writing simple Node scripts, because it was easier to debug what those scripts were doing. We simplified that process even further by occasionally just dipping into Bash scripts. Working with low-level concepts for a while often also gives you better understanding of what you need to abstract. I've worked with codebases where the abstractions all get built first, and it's not uncommon for those abstractions to be built around tasks that are pretty simple and easy to do with lower-level code, at the same time that the abstractions completely ignore the really difficult tasks that are very annoying to do. And once abstractions get baked in, it was time consuming and difficult and expensive to pull them out and rewrite them. Going back to the scripts above, our build process got better because we made it simple to begin with -- a set of scripts, rather than a large established pipeline -- and then as we identified pain points, we started abstracting those pain points away. That allowed us to not waste time rewriting abstractions over and over and instead to have targeted small interfaces that helped us with the actual painful parts of building and deployment. It is surprisingly common for software to be over-abstracted to the point where it is more complicated to deal with than it would be otherwise. I mean, heck, this comes up in web development all the time, it is one of the primary criticisms people have of the JS ecosystem -- that it overcomplicates development. In many cases those complications exist for reasons, they solve real problems that people have had. But also in many cases, someone's individual blog doesn't need any of that, and it would be cheaper and easier for them to build something smaller and simpler. If I can build a site that is one HTML file and one CSS file, and I know that's all I'm going to need, then it's overkill to try and set up a bunch of abstractions on top of that.

hinkley 4y ago

You’re speaking to impedance mismatch which is one of the classic blunders. Systems that don’t use the same jargon as the user base end up having substantial bugs, especially ones the authors insist are features. The abstractions are a bad fit for the problem domain and they break things. I’m in a project that did that massively, at the hands of both architectural astronauts and another common blunder: people who seemed to think the concerns of the user base are beneath them tend to create a fantasy world for themselves where they can pretend they work on something more esoteric than the petty concerns of the people who pay their salaries. Because of the bullshit (and more importantly, the top-heavy sources of that bullshit) we’ve lost a lot of the better people who could have fixed that situation. Meanwhile we are also trying to expand into a new industry, and I can’t help but wonder if we would have been in trouble even if our abstractions had matched our core competency. I would have needed all of those missing people to make the refactors necessary to do that work, so the agents of chaos and delusion are a little vindicated. I have a couple of things I want to button up but they are all fast approaching. I don’t expect to be here in six months. I’ve started fantasizing about my exit interview. In which I will probably suggest that my team is too powerful and isolated from the end user and so needs to be disbanded, its members dispersed into groups one and two steps closer to the users. So as to concretize some of the code and confront them with the day to day struggles of internal customers, dealing with the batshit parts of the code.