As the OP, I was not arguing that Uncle Bob's advice is good; I was arguing that performance is not the reason to reject his advice... unless you are counting nanoseconds, in which case performance is a great reason to reject his advice.
It's a story of two worlds. Casey lives in a world where nanoseconds almost always count. He says OOP is horrible for performance, but he really means it's horrible for performance in that world. But Uncle Bob's book is about a different world: business Java programming from 10+ years ago. There, the overhead of OOP is almost always negligible. One of my main points in the article was just to be aware of the world you are in.
Performance aside, is Uncle Bob's advice good or bad? I think it's a mixed bag. His four main books total 1,552 pages. Some of his advice is rooted in the Java programming world from the 1990s and 2000s, but I think other advice (like "use good names") is valid today in many languages. Sorting through all those pages of advice would require a much longer article; I didn't try to do that; I just tried to address Casey's performance claim, since I think he's totally wrong (in many cases) even while being totally right in other cases.
But performance isn’t the reason to reject his advice: common sense and good taste are more than enough of a reason.
When he wrote Clean Code, Uncle Bob created a monster. Tons of people hold that book up as the Gospel of how to write not just OOP Java code, but all code.
Now is Uncle Bob really to blame for what other people do with the ideas in his book? Absolutely yes. All throughout he writes in a super authoritative tone, snarks at people who disagree with him, and asserts that his 40 years of software engineering experience mean his opinions must be right and that he doesn’t have to explain why.
The reaction to his writing is a product of the way he wrote it, and the reaction sucks. In workplace after workplace I’ve had to push back against people trying to sully nice readable code by blindly and stubbornly applying his principles.
It’s an endless struggle, one that would be helped if, like Merlin Mann (creator of Inbox Zero) he looked at what was happening and disavowed his creation and spent years working to correct the public’s misconceptions. But Uncle Bob doesn’t want to do that, so here we are.
> But performance isn’t the reason to reject his advice: common sense and good taste are more than enough of a reason.
My article and video are responses to Casey's mega-popular video "Clean Code Leads To Horrible Performance," which has 873k views. In it, he falsely claims that clean code always leads to horrible performance when, in fact, it only sometimes does. In my article/video, I explain when OOP/clean code does and doesn't lead to horrible performance.
My goal was to debunk Casey's claim since he was factually wrong and continues to mislead people about this to this day. I partially agree with your point that Uncle Bob's advice is wrong for other reasons. His main four books total 1,500 pages. Some of the advice is good, some is dated, opinionated, or just wrong. Untangling all that would require a much longer and very different article, which wasn't the one I was writing.
I get that Casey’s video is popular (though I wouldn’t call a video with less than a couple million views in it’s first year mega-popular) but I also feel like it’s a bit of a straw man. People don’t dislike Clean Code because the examples aren’t performant, they dislike it because it very stridently and wrongly argues for ways of writing code that are difficult to read, reason about and work with.
And to save you a lot of time: Most of the pages Uncle Bob has written don’t matter. Clean Code was his only book that has significant sway over the software community at large, the other books didn’t have nearly as much influence and don’t really matter to the discussion.
Like, it doesn’t matter if Uncle Bob makes a good point in the middle of a forest when no one is there to hear it. The thing that matters is that he wrote a bad book that made the software engineering community worse.
I am sorry to be tangental, as I am not the GP of this comment thread.
However, I am just curious, since you seem to have a very rational opinion on this topic, what do you think about Domain-Driven Design?
It's not technically CA, but from what I have read, the two can commonly be found together.
My understanding that performance issues with DDD are also not a guarantee, but performance is often the first thing sacrificed in order to maintain "domain purity."
In other words, if you were to develop a size > medium project, what would you use as an architecture?
I only ask because I have been attempting to implement DDD after attempting CA, and I am not convinced the juice is worth the squeeze for either one of the patterns. I am not saying that either design pattern cannot work, but at the same time, I also wouldn't say that a Rube-Goldberg Machine cannot work either.
Casey: Normalized data has an extreme overhead of recalculating things, it's horrible!
Reality: You look at the situation and decide when you need cached values to get acceptable performance. (And I consider most denormalized items in the database to be a form of cached value.)
Yes, there are heuristics given. Except, until clean code, it was not common to even see "use good names" as a principle. In the bad times, pre 2000, a lot of code was just focused on getting it right. The: then make it clean, then fast (in that order)" was not a thing.
In those bad times, the idea of spending time on naming, that naming was even important - was not a widespread thing. The idea that naming all the way down to variables was important - was popularized by Clean Code. Which is to say, the idea to emphasize and care about naming was not widespread at the time, let alone how to do it.
It's a story of two worlds. Casey lives in a world where nanoseconds almost always count. He says OOP is horrible for performance, but he really means it's horrible for performance in that world. But Uncle Bob's book is about a different world: business Java programming from 10+ years ago. There, the overhead of OOP is almost always negligible. One of my main points in the article was just to be aware of the world you are in.
Performance aside, is Uncle Bob's advice good or bad? I think it's a mixed bag. His four main books total 1,552 pages. Some of his advice is rooted in the Java programming world from the 1990s and 2000s, but I think other advice (like "use good names") is valid today in many languages. Sorting through all those pages of advice would require a much longer article; I didn't try to do that; I just tried to address Casey's performance claim, since I think he's totally wrong (in many cases) even while being totally right in other cases.