[rpcope1]

While I agree the "Uncle Bob" cargo cult is IMO dumb, this really rubs me the wrong way:

> You have the vendor pushed acronyms like: ACID, CAP, OLAP, OLTP.

ACID and the CAP theorem in particular has _very_ serious consequences if you're doing anything that isn't a toy with a database, and if there was one thing worth beating into developers, it would be the consequences of those. With the big push on columnar stores and various flexible database options (and replication and etc.) understanding that OLAP and OLTP workloads have very different needs and performance profiles is also something that many (most?) developers seem to miss, and again seems like something that needs to be beaten into a huge cohort of developers. Just because there are some silly/stupid cargo cult acronym around process, does not mean that anything that's an acronym or is confusing to your _garden variety history major_ can just be dismissed. This is part of why we get a lot of the monstrosities that exist out in the world today; there's this really perverse behavior I've seen among people coming from somewhere other than the hard sciences to wave away formalism and anything that smells remotely like math as "oh they're just being dogmatic".

[paulddraper]

Also, DRY, WET, YAGNI are useful ideas.

[DanielVZ]

Yep. That's what they are. Useful ideas. The issue is treating them as rules or excuses for early/unnecesary abstractions.

[bitwize]

We've been fighting this war since Design Patterns at least. Remember those? Engineers who Get Things Done treat them like TV Tropes—useful vocabulary for talking about recurring ideas in software development. Suits in the 2000s treated them like immutable laws.

[DanielVZ]

Oh please don't confuse it with an aversion to formalism. It's quite the opposite. ACID, CAP and others were fantastic research when they came up. But now they are outdated and reductive of the real implications of running databases and distributed systems. That's why I mentioned PACELC being one of my favorite design principles in this matter: https://en.wikipedia.org/wiki/PACELC_design_principle

My criticism of this "Acronym Marketing" is that software engineers get stuck rallying behind acronyms as if they were timeless but to me ACID and CAP are outdated and it would be better if engineers really got into the consequences of running complex systems as you said, and not only repeating acronyms as if they covered the whole story.

OLAP vs OLTP have become marketing talkpoints from Databricks and friends to get people into paying for managed distributed systems when in reality for plenty of workloads Postgres runs just fine. People get stuck in the dichotomy without getting a further understanding of the underlying technology.

Nothing of this is confusing to me. Its reductive.

[bluGill]

Humans like acronyms. You see them all over. If it seems like programmers like them more than others it is only because you are in that field and don't think about other fields. (did you know that Radar, and Scuba are acronyms? probably most readers do as soon as I pointed it out but if asked to come up with a non-programming acronym would have used others)

[DanielVZ]

I was reflecting about this and it may be cultural. In spanish we do have some acronyms they are not as widespread as in english.

[Zababa]

>Humans like acronyms.

Americans, mostly. I don't really know why but acronyms are a very american thing.

[riwsky]

HLA