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.
"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.
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.
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”!?
> 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".
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.
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.
Saying SOLID makes bad code is as over-simplistic as saying SOLID makes good code.
> For my part I'll just say that I have given due consideration to the points you've made, and while I disagree with your conclusions above, I have integrated several of your better ideas, as well as this entire document, into the second edition of Clean Code.
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.
Would you have any good resources to share?
I also found Bob Martin entertaining, but after trying to follow his suggestions I just got into the trap that Casey Muratori shows: even if I don't care about the performance of the code at the start, the amount of abstractions Uncle Bob advises makes it just too easy to make the code extremely hard to optimize later.
Hardly. Not settled down, still less unanimous.
3 of the letters are almost irrelevant in modern code, or barely worth thinking about most of the time.
So what's the value here? Single responsibility?
That kind of thing is now so known that it doesn't really need talking about, like you don't really need to endlessly discuss the database normal forms like people did in the 00s.
Concepts that are worth explaining to beginners, but most code will follow it by default.
Seeing it in job descriptions is more an indicator that a company has an inexperienced lead more than anything else.
"That kind of thing is now so known that it doesn't really need talking about, like you don't really need to endlessly discuss the database normal forms like people did in the 00s."
Has humanity progressed so much that we no longer forget the lessons of the past?
That would indeed be a good thing but I am not so sure of it.
He's legacy is making code brake even now.

I learned to program through online documentation and projects. I also read books but I don’t consider them pivotal to my programming or software engineering career. Some of the books I read are:
Designing Data-Intensive Applications: really good book.
The Mythical Man-Month: felt outdated but useful to understand where the industry came from
Design Patterns, Elements of Reusable Object-Oriented Software: I don’t remember much. I think I read this too early to fully grasp all patterns but at least it gave me a general understanding of Design Patterns
Clean Code: this book felt like a bunch of advice from a senior engineer, but much of it not being verifiably good advice. As an outsider it at least made me aware that I had to be conscious that my code was going to be read.
One day an interviewer asked me about design patterns and SOLID principles. I started talking about the ones I learned from the Gang of Four book, but he stopped me and said that he meant SOLID principles, and that he was not sure what I was talking about. Now in retrospect I know he was just reading the rubric without knowing much about the topic but I left that interview confused.
So I googled SOLID principles and landed on a video where this “uncle bob” dude spent a good chunk of his introduction talking about the water molecule only to then take more than 10 minutes to explain that the rate of new programmers was constantly doubling and that as long as this rate of growth continued, half of all engineers would always be inexperienced. Then after a whole 20 minutes into the talk he starts a real introduction when he explains that bad code slows you down (no shit, Sherlock), that code rigidity, coupling is bad, only to really get into the topic 30 minutes in.
Nearly half of the talk could have been fully explained in 5 minutes.
Around that time I was in my 3rd year studying history. I had to read and write 1000s of pages a week. I learned that not everyone writes the same and that different disciplines have different writing styles. If you were writing history there’s a structure and vocabulary you were implicitly supposed to follow, same for other humanities and social sciences, and I assume it’s the same for the hard sciences as well.
I see them as cultural rules that arise from reading each other’s work until some writing culture emerges. So in order to get good grades I’d try to mimic my professors and their preferred authors writing and investigation styles for my essays. I started to get a feeling of what kind of author I was reading, how dense their writing was, the pacing, and how they mixed narrative with argumentation.
Also for reasons I won’t explain here by around that time I had seen around maybe 4 or 5 successful scams/cons very closely. Like actually helplessly being around the con-man and the victim as the con was happening, for months.
All this to say that I had developed a sense for understanding how people wrote and spoke.
Not to disrespect “uncle bob” but everything he wrote and talked made me feel like I was being scammed out of my time while trying to convince me this was the talk/writing of a genius programmer.
First of all there’s the “uncle bob” nickname, which has this backstory:
Just to be clear, the name “Uncle Bob” was given to me by a coworker in 1989. It was in my email and uunet signature for years. (There are kids out there who don’t know what uunet was). The name stuck, and I eventually adopted it as a brand.
– Robert C. Martin, https://news.ycombinator.com/item?id=7713646
It’s an ok explanation but that doesn’t change the fact that the name still feels manipulative for someone that was trying to establish a brand of being a dependable senior engineer.
Also as a side-note, OF COURSE THERE ARE KIDS THAT DON’T KNOW WHAT UUNET WAS.
We get it. You are an “experienced” programmer.
Engineers have a tendency to assume they are impartial machines that are able to see the objective truth, but if there’s something that I learned while studying history is that the only way to be able to strive to be objective is to embrace the fact that you are a subjective human being. The more objective you assume you are, the more easily manipulated you can be by subjectivity, be it your own subjectivity or others. The fact that I had coworkers speak fondly of “Uncle Bob” as if he was a real wise uncle and cite him to justify some convoluted dependency injection shenanigans made all my manipulation-senses go off.
Then we have the actual prose he uses. As I said before, his style is overly dependent on filler content. Of course it’s not just random filler content. It’s stuff he can confidently say while scratching his chin, drop a witty joke here and there, and look smart in the process. If my university professors caught me writing like that they’d deduct points for wasting their time. I saw this done plenty of times in university. Especially from us students. When we wouldn’t be able to fill in the required pages we’d resort to over-citing sources and adding slightly related narrations that would have made no impact on arguments other than extend their length.
The way I used to read filler-ridden history books and essays was to just scan the text first, highlighting the actual content and then do a proper read afterwards. The same can be done with Uncle Bob’s books.
“You can see how smart Robert is by watching only a small bit of the workshop, talking (and a lot) about software principles in development, astronomy, math, history, corporate world, and other subjects that most, what called ‘programmers’, might not even have heard about it!”
– Someone who apparently liked the filler content
Now I must admit that this is also partly a matter of taste. But in my opinion there’s some responsibility to bear if you sell yourself as the source of senior experience to newcomers to the craft. In the best case you are wasting their time. Worst case scenario you are manipulating them into dogmatic behaviour through low substance content that requires quite some faith on the author.
Boy do software engineers love their acronyms.
You have the agile acronyms like: SOLID. DRY. KISS. YAGNI.
You have the vendor pushed acronyms like: ACID, CAP, OLAP, OLTP.
The list is endless. Some of them I can get behind. Others have a well researched and honest origin (ACID, CAP) but at the same time it feels like these have proliferated because they have served as marketing bullet points and slogans for both corporations and “agile” proponents. If you really look into it, some SOLID principles are anything but solid when you hold them to scrutiny. The amount of complexity I’ve seen from engineers needlessly DRYing their code has cost endless hours. And I could go on and on on the topic of people taking these acronyms to the extreme in order to justify their practices.
Acronyms like ACID, CAP, OLAP, OLTP, etc. are included as foundational knowledge for interviews but in practice there are much better alternatives for understanding software systems. The unglamorously acronymed PACELC design principle is one of my favorites.
To be fair with engineers this seems to be part of US culture. These people use acronyms for everything. When I started working with US-based colleagues I had to google a new acronym every other week.
To me the worst offender in the acronym world is EBITDA. At that point you have a whole new word. Just invent a new concept please. Something like Core Operating Earnings or something.
When you write a history book you don’t call it “Clean History of Hispanic Colonialism” or “SOLID History of 20th Century Chilean Agricultural Culture”. You usually call it what it is. 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.
I’ve seen people call their classes (especially when they come from Java) something like SimpleRepository. Why not just Repository? What if I don’t find your class simple enough to be awarded that name? Can I just remove it? What if it grows into a ComplexRepository?
Same goes with books.
Even with all the experience uncle bob might have, he’s not entitled to calling his own code clean. Plenty of his examples in the “Clean Code” book can be deemed not clean at all and even contradictory to his own principles.
Software engineering culture is overly dogmatic and subjective. We try to think of ourselves as more objective than we are, but we aren’t. We fall into marketing techniques like sheep being herded by a cute border collie.
I’m sorry, Uncle Bob. I used you as a punching bag here. I don’t like your books or talks, but at least it’s honest work. Just a tad too manipulative for my taste.
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.