I clicked the link hoping for a critique of the ideas in SOLID and Clean Code, but what I got was an ironically long-winded critique of Bob Martin’s speaking style.
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.
If you want something real, look at Clean Code Horrible Performance youtube video if you haven't.
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.
Sorry if the title mislead you. To me criticizing SOLID and Clean Code directly is like beating a dead horse, so here I wanted to criticize the way they are presented because that's a big reason why it's successful.
I’m not really a fan of the ideas. They’re not wrong, exactly, but I think they’re overstated. Instead, here’s some alternatives:
For design, Evans’ Domain-Driven Design does a good job of representing classic object-oriented design, and Fowler’s Patterns of Enterprise Application Architecture is good for expanding past business logic to larger systems.
For coding habits, “The Pragmatic Programmer” is a classic for a reason.
What I dislike about the term "clean" code is that it dismiss objective criteria.
"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.
> A program must be maintenable, efficient, observable, testable, scalable, performant, readable, secured.
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 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.
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.
I think a major meta-problem with patterns is that the straight-forward ones get written about the most, and/or read about the most. Now we have tons of devs out there who pledge allegiance to some subset of whatever patterns they've come across. I wonder if that prevents/delays pattern transcendence to see the nuance.
Uncle Bob does a bad job talking about trade-offs, but there's still value in stuff like SOLID. The problems start when people blindly obey or ignore design principles.
Saying SOLID makes bad code is as over-simplistic as saying SOLID makes good code.
The trouble with SOLID is that it's mainly an artifact of old languages and paradigms.
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.
> So what's the value here? Single responsibility? That kind of thing is now so known that it doesn't really need talking about
Except I see people getting it wrong constantly, even in the comments here. Its not about keeping code together that's related in functionality, this about keeping code separate by stake holder. For example, if you have two bosses that keep asking for changes related to their departments, you keep their relevant code separate, so when you have to keep updating it for one boss, you don't break the code related to the other boss, and vice versa.
Does it work? I don't know, never been in this situation.
Single Responsibility was written about nearly 40 years after cohesion was grafted into software design from an actual architect's (like buildings and cities, absolutely not software o doctoral thesis.
"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.
If single responsibility is so well known, when did I just this week see some code that violated that from a senior engineer? That code past review by a couple other programmers, without me looking at it and pointing out how horrible it was.
Choose a convention and stick with it. Your chosen conventions could be the worst fit for your domain, but the code following "a" convention ensures that people jumping in later can actually follow along and it makes refactoring at least bearable.
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 tend to agree with this take. If you do something wrong at least doing it consistently will be more valuable than not. Unfortunately dogma is not easy to avoid. Even it wasn't for Bob's Clean Code, some other guy would distill some patterns, market another book with a catchy title that'd be inevitably somewhat misunderstood and misused.
These rules are all stuff that you probably should think about at some time. But they're often taught as strict rules, which I don't think is a good idea.
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.
> 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.
Bob can learn and change. Good for him. Can you? (you the reader, not the person I'm responding to - except when they by reading this comment are the same person)
Uncle Bob is awesome, maybe some of his ideas aren’t iron clad but he embodies a great engineer and person. Every time I’ve listened to (https://youtu.be/UBXXw2JSloo) or (now) read interviews the guy is humble, listening, and it would seem extremely genuine.
I guess by now it's pretty settled down and unanimous that SOLID is an extremely bad way to organize your code, and that Clean isn't very good and has about the same odds of helping or harming you.
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.
Uncle Bob is a snake oil salesman. Not sure he realizes it himself though.
The whole SOLID, OOP design patterns era was one of the worst things to have happened to programming.
I always thought I was the one that sucked but now I'm absolutely certain that whole zeitgeist was total crap.
I think it's not as bad as a snake oil salesman that knew their product was not good.
In reality, most software design and dev advice is well intentioned but is just based on personal opinion, they don't really have much science behind them.
This is not to say they should be completely ignored, it means there should be a healthy does of using your own brain and experience on any of this stuff.
I would add, simple data in / data out functions. Composable functions. Value types > reference types. Keep your state in order! Consolidate your state, dont shatter your state around a bunch of "objects"
Re: Java classes called "SimpleFoo": that's usually because `Foo` is an abstract class or interface, and `SimpleFoo` is the version you actually use most of the time, unless you absolutely have to implement a `MyReallyComplexFoo` for some specific purpose.
Ahh interesting. So it's Java convention/best practices being ported to other languages. Nothing wrong with using "simple" that if you explain it that way. I stand myself corrected.
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".
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.
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.
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)
This is a tedious, meandering, almost self-contradictory article.
> 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.
The only thing worse than a long-winded explanation that finally gets around to the topic you're interested in (in his case an explanation of SOLID) is a long-winded explanation that never gets around to it (in my case a refutation of SOLID).
Pick better data structures such that you can use simple language elements to manipulate said data. If you're writing a dozen lines of code to abstract 2 lines of logic, you're not doing anyone any favors.
This sort of object oriented programming was doomed to fail because it requires thoughtful world building and not a direct assault on the ticket you were assigned.
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.
Pretty much every item besides the Open Closed Principle which deals with deals with future changes touch on being able to snap pieces that know as little as possible about each other together to create the final product while being robust to change in the underlying pieces.
This comes out in the practical world in being able to make Java libraries that don't need to be recompiled or redistributed because of changes to other parts.
I've yet to find a panacea. For example, I thought DRY was, but found its not the case (test scenarios). I've yet to find altruisms past "everything in moderation". If you do choose a style and stick to it though at least it's consistent.
The article has no constructive way about it at all.
Says clean code doesnt feel clean but doesnt even show one line of code apart from not having a better way.
I read Clean Code when I was a beginner and found it revealing, but also annoying in parts, like the idea to 'do not use functions with more than 2 parameters.'
To see really elegant and great code, I recommend looking in books. I have seen elegant code in: SICP, The Little Schemer, Software Design for Flexibility.
Problem is those are books. They are written by great programmers, but the problems are mostly toys - useful elegant examples, but the longest in SICP is still only a couple pages long. Sure it is cool they implemented SCHEME in a couple pages (you can tell how old the edition I have is), but if you wanted a real SCHEME implementation it would be much longer since you will want to spend a lot of time on optimization. If you want your SCHEME to be used it needs to have a standard library so that you don't have to write sort, trees, and all the other things we expect from a useful language. If you want this done in a reasonable amount of time you will need multiple programmers and in turn nobody will understand the full and so there will be some code that isnt' elegant.
> Software engineering culture is overly dogmatic and subjective.
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".
Programming is human. Obviously there will be cultures (and cults) that spring up and die down all the time. I probably pissed off a few colleagues over the years by rejecting their arguments because they were “appeals to authority” that I did not recognize as authorities in the particular problems we were solving at the time. Hate cargo cult programming, but admit I fell into that trap often enough in my early years. Gotta start somewhere.
I am sorry but nothing in the article clearly lays out how solid/clean code doesn't feel solid or clean. It seems to be a criticism of a specific person. What am I missing?
Every webdev team out there is doing the same architectural fuckup : using exactly one database, and coupling everything to that. The Controller points straight at the Service which points straight at the DB. Even the basic units of your logic (User, Payment, Document) do not exist without reference to the (ONE) DB. They're called 'Entities'.
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?
In frontend it's coupling everything to specific backend urls and it's literally billion times worse. People fire up a frigging headless browser and set up backend servers to test a few microseconds of logic. You don't get to test much at all before everything takes too long and becomes too flaky.
At best solid haters/unaware will "solve" this by mocking everything, which just has a different set of problems and is just as bad. The only way to truly have actual satisfying solution is DI.
Did Uncle Bob rape everyone's grandma, because the amount of anger here for him and his work is insane. I'm guessing he wrote his books with the intention of helping others, and saw an opportunity to make a little coin at the same time. But you'd think he was software's Hitler the way people talk about him these days.
I was given Clean Code as a junior developer... didn't think it was mind blowing, but I used the parts that made sense and left the parts that didn't... what you're supposed to do anytime you're exposed to other peoples opinions. And I never felt a need to follow it blindly. If your code got inappropriately criticized by your leads or managers for not being Clean or SOLID enough, or they forced you into following Clean Code like it was the bible, then be mad at those guys!
I clicked the link hoping for a critique of the ideas in SOLID and Clean Code, but what I got was an ironically long-winded critique of Bob Martin’s speaking style.
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.
If you want something real, look at Clean Code Horrible Performance youtube video if you haven't.
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.
https://youtu.be/tD5NrevFtbU?is=vuVfjbsINQrtfvbC
Regardless of style, Uncle Bob's Enterprise Java Clean Code opinions are overly dogmatic and harmful in most places.
I pick and choose the bits I think make reasonable sense, an go with better options myself.
This is the right approach, unfortunately many of my coworkers in software are ridiculously dogmatic about it
I found this https://vimeo.com/157708450 video quite interesting critique of SOLID.
Sorry if the title mislead you. To me criticizing SOLID and Clean Code directly is like beating a dead horse, so here I wanted to criticize the way they are presented because that's a big reason why it's successful.
I felt the same. Even the off topic arguments don't many sense. Some sort of weird rant about acronyms that made no sense to me. Waste of time
> [..] There’s plenty of other ways to learn about the ideas that are more concise.
Would you have any good resources to share?
I’m not really a fan of the ideas. They’re not wrong, exactly, but I think they’re overstated. Instead, here’s some alternatives:
For design, Evans’ Domain-Driven Design does a good job of representing classic object-oriented design, and Fowler’s Patterns of Enterprise Application Architecture is good for expanding past business logic to larger systems.
For coding habits, “The Pragmatic Programmer” is a classic for a reason.
Thanks for the tips!
You are not alone in his style, but in what he actually says, all of which seems to me to be wrong.
He seems to prefer being called Uncle Bob.
What I dislike about the term "clean" code is that it dismiss objective criteria.
"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.
> A program must be maintenable, efficient, observable, testable, scalable, performant, readable, secured.
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 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.
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.
Yeah seriously what's the test of maintainable that couldn't be applied to the word clean?
What about the latest book Tidy First https://a.co/d/0b1hRqEV
The #1 problem of most clean code, or microservices, or other architectural patterns is taking a correct observation to a logical extreme.
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.
Yeah, don't take it too far.
You can reduce to a Single Responsibility, but try not to step beyond that into Zero Responsibility.
Do Interface Segregation, not Interface Apartheid.
And only invert your dependencies an odd number of times, otherwise you're back to where you started.
I fully agree.
I think a major meta-problem with patterns is that the straight-forward ones get written about the most, and/or read about the most. Now we have tons of devs out there who pledge allegiance to some subset of whatever patterns they've come across. I wonder if that prevents/delays pattern transcendence to see the nuance.
Uncle Bob does a bad job talking about trade-offs, but there's still value in stuff like SOLID. The problems start when people blindly obey or ignore design principles.
Saying SOLID makes bad code is as over-simplistic as saying SOLID makes good code.
The trouble with SOLID is that it's mainly an artifact of old languages and paradigms.
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.
> So what's the value here? Single responsibility? That kind of thing is now so known that it doesn't really need talking about
Except I see people getting it wrong constantly, even in the comments here. Its not about keeping code together that's related in functionality, this about keeping code separate by stake holder. For example, if you have two bosses that keep asking for changes related to their departments, you keep their relevant code separate, so when you have to keep updating it for one boss, you don't break the code related to the other boss, and vice versa.
Does it work? I don't know, never been in this situation.
https://en.wikipedia.org/wiki/Single-responsibility_principl...
Single Responsibility was written about nearly 40 years after cohesion was grafted into software design from an actual architect's (like buildings and cities, absolutely not software o doctoral thesis.
"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.
On the contrary, the new trend of telling a bot to write code automates disregard for architecture.
If single responsibility is so well known, when did I just this week see some code that violated that from a senior engineer? That code past review by a couple other programmers, without me looking at it and pointing out how horrible it was.
And I saw a "senior" engineer make a database table without foreign keys just 3 years ago.
Some people are just bad.
Doesn't change my point that the debate is long settled, SRP is incredibly well known and the de-facto way of coding today.
Choose a convention and stick with it. Your chosen conventions could be the worst fit for your domain, but the code following "a" convention ensures that people jumping in later can actually follow along and it makes refactoring at least bearable.
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 tend to agree with this take. If you do something wrong at least doing it consistently will be more valuable than not. Unfortunately dogma is not easy to avoid. Even it wasn't for Bob's Clean Code, some other guy would distill some patterns, market another book with a catchy title that'd be inevitably somewhat misunderstood and misused.
These rules are all stuff that you probably should think about at some time. But they're often taught as strict rules, which I don't think is a good idea.
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.
For some actual code and comparison of principles behind Clean Code see:
https://github.com/johnousterhout/aposd-vs-clean-code
And at the end of that Bob says:
> 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.
Much faster and more efficient and better to just buy a copy of:
https://www.goodreads.com/en/book/show/39996759-a-philosophy...
Bob can learn and change. Good for him. Can you? (you the reader, not the person I'm responding to - except when they by reading this comment are the same person)
Uncle Bob is awesome, maybe some of his ideas aren’t iron clad but he embodies a great engineer and person. Every time I’ve listened to (https://youtu.be/UBXXw2JSloo) or (now) read interviews the guy is humble, listening, and it would seem extremely genuine.
A definite Uncle!
I guess by now it's pretty settled down and unanimous that SOLID is an extremely bad way to organize your code, and that Clean isn't very good and has about the same odds of helping or harming you.
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.
> I guess by now it's pretty settled down and unanimous that SOLID is an extremely bad way to organize your code
Hardly. Not settled down, still less unanimous.
I'm not sure you can even get majority agreement of what SOLID code looks like, let along unanimous agreement on it being bad.
You don't know many c# devs, then.
I have met exactly 1 developer that both followed the Microsoft recommended practices and didn't think they were bad.
His legacy is making code brake even now.
"Extremely bad"? What are the actual material consequences of the decision? Relate it to business outcomes
Why are you talking to the OP like they're a bot?
They can slap it into ai and get the answer if they cant think of it themselves
Uncle Bob is a snake oil salesman. Not sure he realizes it himself though. The whole SOLID, OOP design patterns era was one of the worst things to have happened to programming.
I always thought I was the one that sucked but now I'm absolutely certain that whole zeitgeist was total crap.
> Uncle Bob is a snake oil salesman
I think it's not as bad as a snake oil salesman that knew their product was not good.
In reality, most software design and dev advice is well intentioned but is just based on personal opinion, they don't really have much science behind them.
This is not to say they should be completely ignored, it means there should be a healthy does of using your own brain and experience on any of this stuff.
What do you prefer?
KISS, YAGNI, Program with intent, functional style.
I would add, simple data in / data out functions. Composable functions. Value types > reference types. Keep your state in order! Consolidate your state, dont shatter your state around a bunch of "objects"
Re: Java classes called "SimpleFoo": that's usually because `Foo` is an abstract class or interface, and `SimpleFoo` is the version you actually use most of the time, unless you absolutely have to implement a `MyReallyComplexFoo` for some specific purpose.
Ahh interesting. So it's Java convention/best practices being ported to other languages. Nothing wrong with using "simple" that if you explain it that way. I stand myself corrected.
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".
Also, DRY, WET, YAGNI are useful ideas.
Yep. That's what they are. Useful ideas. The issue is treating them as rules or excuses for early/unnecesary abstractions.
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.
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.
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)
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.
>Humans like acronyms.
Americans, mostly. I don't really know why but acronyms are a very american thing.
HLA
This is a tedious, meandering, almost self-contradictory article.
> 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.
The only thing worse than a long-winded explanation that finally gets around to the topic you're interested in (in his case an explanation of SOLID) is a long-winded explanation that never gets around to it (in my case a refutation of SOLID).
Pick better data structures such that you can use simple language elements to manipulate said data. If you're writing a dozen lines of code to abstract 2 lines of logic, you're not doing anyone any favors.
I'm on 4G mobile, that stock photo of sheep is 19MB PNG file! Thanks.
sorry about that. compressed it into a 237 KB jpeg
This sort of object oriented programming was doomed to fail because it requires thoughtful world building and not a direct assault on the ticket you were assigned.
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.
What is most of SOLID?
Pretty much every item besides the Open Closed Principle which deals with deals with future changes touch on being able to snap pieces that know as little as possible about each other together to create the final product while being robust to change in the underlying pieces.
This comes out in the practical world in being able to make Java libraries that don't need to be recompiled or redistributed because of changes to other parts.
I've yet to find a panacea. For example, I thought DRY was, but found its not the case (test scenarios). I've yet to find altruisms past "everything in moderation". If you do choose a style and stick to it though at least it's consistent.
> I've yet to find a panacea. For example, I thought DRY was, but found its not the case (test scenarios).
What would it have meant for DRY to be a panacea? That doesn't make much sense.
The article has no constructive way about it at all. Says clean code doesnt feel clean but doesnt even show one line of code apart from not having a better way.
I read Clean Code when I was a beginner and found it revealing, but also annoying in parts, like the idea to 'do not use functions with more than 2 parameters.'
To see really elegant and great code, I recommend looking in books. I have seen elegant code in: SICP, The Little Schemer, Software Design for Flexibility.
Problem is those are books. They are written by great programmers, but the problems are mostly toys - useful elegant examples, but the longest in SICP is still only a couple pages long. Sure it is cool they implemented SCHEME in a couple pages (you can tell how old the edition I have is), but if you wanted a real SCHEME implementation it would be much longer since you will want to spend a lot of time on optimization. If you want your SCHEME to be used it needs to have a standard library so that you don't have to write sort, trees, and all the other things we expect from a useful language. If you want this done in a reasonable amount of time you will need multiple programmers and in turn nobody will understand the full and so there will be some code that isnt' elegant.
> Software engineering culture is overly dogmatic and subjective.
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".
Programming is human. Obviously there will be cultures (and cults) that spring up and die down all the time. I probably pissed off a few colleagues over the years by rejecting their arguments because they were “appeals to authority” that I did not recognize as authorities in the particular problems we were solving at the time. Hate cargo cult programming, but admit I fell into that trap often enough in my early years. Gotta start somewhere.
I agree with the point about dogmatism, but I have so many other issues with this piece.
I mean... how do you even make the comparison between "A Handbook of Agile Software Craftsmanship" and "History of Hispanic Colonialism”!?
I am sorry but nothing in the article clearly lays out how solid/clean code doesn't feel solid or clean. It seems to be a criticism of a specific person. What am I missing?
Every webdev team out there is doing the same architectural fuckup : using exactly one database, and coupling everything to that. The Controller points straight at the Service which points straight at the DB. Even the basic units of your logic (User, Payment, Document) do not exist without reference to the (ONE) DB. They're called 'Entities'.
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?
In frontend it's coupling everything to specific backend urls and it's literally billion times worse. People fire up a frigging headless browser and set up backend servers to test a few microseconds of logic. You don't get to test much at all before everything takes too long and becomes too flaky.
At best solid haters/unaware will "solve" this by mocking everything, which just has a different set of problems and is just as bad. The only way to truly have actual satisfying solution is DI.
https://trolololo.xyz/software-evangelism-mess
Did Uncle Bob rape everyone's grandma, because the amount of anger here for him and his work is insane. I'm guessing he wrote his books with the intention of helping others, and saw an opportunity to make a little coin at the same time. But you'd think he was software's Hitler the way people talk about him these days.
I was given Clean Code as a junior developer... didn't think it was mind blowing, but I used the parts that made sense and left the parts that didn't... what you're supposed to do anytime you're exposed to other peoples opinions. And I never felt a need to follow it blindly. If your code got inappropriately criticized by your leads or managers for not being Clean or SOLID enough, or they forced you into following Clean Code like it was the bible, then be mad at those guys!