[bcrosby95]

> On re-reading Sandi’s original article it says kind of what I remember it saying, but it also… kinda doesn’t? There’s a lot more talk about programmers honoring the abstractions of elders who came before them

That's because the original article is so clearly about tearing down bad abstractions, but a large majority of programmers - based upon discussion about the article - seem to never get past the first part of it.

Given a long enough time horizon, all abstractions turn bad. The solution isn't to not abstract. The solution is to tear them down when they go bad. And if you don't learn to tear down bad abstractions, your codebase will devolve into shit regardless of what you do.

[Zababa]

That may be projection on my part, but I feel like lots of programmers (me included, of course) have a hard time accepting code as a living thing, and would rather build something that "lasts forever". I feel like this is the kind of thinking that pushes us to try to make abstractions that cover all of the cases, spend lots of time on things with little value (in a business context) to "make it right", flaws like that.

Reading the "original SOLID paper" [1] was enlightning to me. The initial assumption is that software rots, or gets less flexible with time. The best way to prevent that is to identify the part that is the least flexible/most rotten and replace it. But for that you need two things: being able to clearly identify parts of the software, and being able to replace them. This is where modularity and abstractions comes in. But this is also where the good old delete key comes in. This is where modularity and abstractions comes in.

Building software from parts, expecting to replace them does leads to abstractions, but different ones from building software expecting it to never be replaced. And, in my opinion, the first kind is easier to deal with.

[1]: https://web.archive.org/web/20150906155800/http://www.object...

[cogman10]

> Given a long enough time horizon, all abstractions turn bad. The solution isn't to not abstract. The solution is to tear them down when they go bad.

I disagree with this analysis. Abstractions certainly go bad, but I don't think it's correct to say all abstractions go bad.

The solution I took from Sandi's post was two-fold.

* Don't prematurely abstract, it's better to live with a little duplication vs aggressively eliminating it.

* Don't hold abstractions sacred, when you start seeing an abstraction with too many conditionals, consider breaking apart the use-cases to see if there are actually 2 distinct abstractions happening.