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.
datadrivenangel 31 minutes ago [-]
Regardless of style, Uncle Bob's Enterprise Java Clean Code opinions are overly dogmatic and harmful in most places.
giancarlostoro 25 minutes ago [-]
I pick and choose the bits I think make reasonable sense, an go with better options myself.
xiphias2 22 minutes ago [-]
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.
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 modern society or a football team works, and S brings D because specialization invokes good relationship ("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.
marcosdumay 48 minutes ago [-]
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.
AnimalMuppet 18 minutes ago [-]
> 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.
Cpoll 31 minutes ago [-]
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.
mattmanser 5 minutes ago [-]
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.
rpcope1 49 minutes ago [-]
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 42 minutes ago [-]
Also, DRY, WET, YAGNI are useful ideas.
fabian2k 42 minutes ago [-]
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.
rdiddly 16 minutes ago [-]
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).
zelphirkalt 19 minutes ago [-]
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.
sriramgopalan 12 minutes ago [-]
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?
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.
breckenedge 51 minutes ago [-]
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.
ilitirit 43 minutes ago [-]
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”!?
sublinear 40 minutes ago [-]
> 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".
Rendered at 18:02:40 GMT+0000 (Coordinated Universal Time) with Vercel.
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 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
"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 modern society or a football team works, and S brings D because specialization invokes good relationship ("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.
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.
Hardly. Not settled down, still less unanimous.
Saying SOLID makes bad code is as over-simplistic as saying SOLID makes good code.
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.
> 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".
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.
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.
I mean... how do you even make the comparison between "A Handbook of Agile Software Craftsmanship" and "History of Hispanic Colonialism”!?
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".