Abstraction is expensive

I would argue that abstractions are usually expensive.

It's just that sometimes not doing something expensive is also expensive. Getting your car regularly maintained is expensive, so is not doing that.

The issue with abstractions is that people have not internalized them as "an expensive thing we do to prevent ourselves from running into expensive problems later"; they're internalized them as a zero/low-cost process that has no downsides and thus should be pursued all the time.

It's like if people said, "not getting your oil changed will be more expensive, and therefore I get my oil changed every other week."

I kind of think that the only reason that the phrase "abstractions are expensive" sounds like a controversial take is precisely because people have not internalized that abstractions are not a binary good/bad thing and that they should be applied situationally, because they do have maintenance costs and development costs.

Sure, the statement isn't wrong. But the content is mostly about making good/consistent choices given the situation.

complex != overengineered and/or overgeneralized one

some technical problems are actually just complex

sure, but it's easier to solve a complex problem by building an abstraction that is more complex than the problem requires, that to build an abstraction that is as simple as possible (given the complexity inherent to the problem). then, once you have your too-complex abstraction, it can be difficult to restrain yourself, especially as an eager junior developer, to not take your amazing feat of abstraction engineering to its logical, generalized conclusion... or at least die trying.

"see, now, every time I want to do x, all I have to do is y and z, instead of a, b, c, and d" is an incredibly addictive drug! (I write this as a recovering addict.)

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.