Martin and I have our differences, but this article isn’t really useful. Martin has a brand and a style. A lot of people find it engaging and entertaining. If you don’t, that’s fine, there’s plenty of other ways to learn about the ideas that are more concise.

"I did it like that because it's cleaner" is a non sense. A program must be maintenable, efficient, observable, testable, scalable, performant, readable, secured. Each criteria can be objectively measured in a kind of radar diagram and can be maximized as long as it does not sacrifice another criteria. Form follows function.

Even "simple" (from KISS) is too vague, fortunately in the conference "simple made easy" Rich Hickey defines what is simple: not interleaved. simple comes from sin plex, the opposite of con plex. Not always easy to make something simple.

However I don't see anything wrong with SOLID. Separation of concerns is how a modern society or a football team works, and S brings D because specialization involves good relationships ("no man is an island" wrote John Donne ), and D is strongly related to L. I has no drawbacks.

However I don't separate data from business logic anymore (no data access layer). Business logic applies on data, not on objects that hide data. Translating a ER diagram into anemic classes while the DBA do the same in the DB does not have any value and forces to use obstruction pattern like repository. If entity classes have properties and methods (a Plane class that has a 'takeOff' and 'land' methods for instance) it is different but must most backend I see don't implement entity classes that way. Because their classes represent data, not animated concept. Player class with a shoot method might makes sense for a video game, User class with a addComment method for a CRUD app makes less sense to me.

Decomposition is good. Too much decomposition recreates complexity in the interactions.

Immutability is good. Immutability everywhere creates gymnastics with more mental load.

Extensibility is good. Extensible-everything is reduces usability.

Program isolation is good. Too much isolation melts your laptop into a Docker-shaped puddle.

Having the restraint to not apply your pet idea to everything under the sun is the mark of a mature programmer and indeed a mature person.

Saying SOLID makes bad code is as over-simplistic as saying SOLID makes good code.

I personally don't like when people stick to SOLID like it's the holy hammer, but nearly every serious programming language has a convention on how to write SOLID code, and it will be followed, which makes my job easier if I'm new to the codebase.

I always thought I was the one that sucked but now I'm absolutely certain that whole zeitgeist was total crap.

In the end many of them are still quite subjective. It is useful to try to avoid mixing unrelated stuff into the same class. But trying to religiously find the boundary to what a single responsibility means in each specific case is a waste of time.

But extending the complaint to all acronyms isn't helpful. ACID, OLAP, EBITDA, etc are perfectly good names with clear meanings that can be easily discovered.

https://github.com/johnousterhout/aposd-vs-clean-code

> 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".

> To me people calling their code or software “Clean”, “Easy”, or “Simple” has always felt wrong. You aren’t entitled to declare your own creation to have some subjective trait you strived for when writing it.

Follows:

> The more objective you assume you are, the more easily manipulated you can be by subjectivity, be it your own subjectivity or others.

I'm happy to go on record stating the former is more forgivable than a lazy false truism or platitude.

It you look at most of SOLID it is about building little pieces that eventually will fit together and rules to avoid incompatibilities when the world you built comes together.

It doesn't have to be. You can have standards without clinging onto them for dear life like you're about to be swept away in a flood.

> This is not a specific critique of the contents or ideas in SOLID or Clean Code. It’s about how it presents itself and how that made me feel.

Yeah, this blog post added to the dogma. Someone will read this and just look for something else to cling on to. For critique to work, you can't be injecting even more of your superficial opinion, and the readers have to care instead of impatiently looking for "the answer".

I mean... how do you even make the comparison between "A Handbook of Agile Software Craftsmanship" and "History of Hispanic Colonialism”!?

This is the key that most people miss.

The second thing most people miss is most of the time efficient, scalable, and performant are good enough. Not always, there are no absolutes, but most of the time you can safely compromise those 3 without any problem that the real world will notice. In general maintainable has proven to be the hardest/most expensive, and so clean code is most important (don't confuse with Clean Code as a book or any set of rules puts it). Indeed, observable and testable are just different ways to express maintainable. (the first is you can understand what went wrong, and the second you can ensure your changes don't break something else).

Secure is the final thing I didn't mention. this is becoming more and more important. It may even become more important than maintainable in the future.

I don't think it's nonsense. "Cleaner" here is just a different word that falls under your categories of readable and maintainable. More toward readable. Different word, same meaning.

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.

It's a nightmare to test. Every click of a 'unit' test requires the database to stand up, be initialised (check its 'Migrations' have been run, if not actually running them), cleaned up afterward, and maybe a few microseconds of that time will be used for testing your logic.

(I don't know what the equivalent frontend fuckup would be - running every unit test through the browser? digression..)

Architecturally it means you can't change dependencies. Do you want a cache in addition to the DB? Kafka? NoSql? A strangler or sidecar pattern where you live-live migrate from one system to another with no down-time? If you manage your dependencies, these are all do-able ideas. If you don't, they are impossible to do, and then, through the lens of all-classes-belong-to-the-one-true-database, you'll perceive those other ideas as terrible, even though it's actually your architecture which is terrible.

DIP says to guard against these kinds of things. Look inside your TaxService and TaxRule classes - you should not see any direct or indirect dependencies to database code. (Just like you shouldn't see any references to the Browser, the DOM, or Kubernetes.)

No dependencies means you can run all 30-50 unit tests in your TaxServiceTests in about 10 millis, and in parallel with whatever other tests are going on.

----

Now take a step back. Everything I wrote above is just the D in SOLID. (And I didn't even get to 'how to do it'; I only covered 'why' and 'how to check if you did it')

Do you see anyone actually engaging with these concepts? cos I don't.

There is a much lower barrier to entry in saying:

"I saw my teammate try to do SOLID and it was the worst so I always avoid it"

"Bob is a right-wing weirdo!"

"SOLID is dogma and it's bad to be dogmatic so SOLID is bad"

"I like a bit of SOLID but NOT TOO MUCH because I'm a pragmatic person"

If you look at the actual principles, what the hell does that last one mean? You only need to maybe stand up the database a little bit to check your tax logic?