Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is the same guy from the failed sudoku solver... http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...

Maybe he had also tried TDD "wrong"? Or maybe he's just another snake oil salesman, like "uncle" Bob?



I think Uncle Bob also promoted AGILE very hard. But if we mention Uncle Bob, we also should mention GoF (If you have problems with OOP architecture, you aren't doing it right, you aren't abstracting enough, you should abstract the existing abstractions, too).


we also should mention GoF

Which of the four GoF does this apply to. I've never seen any of them make the arguments you are claiming they're making. I certainly don't recall it being made in "The Book".


I’m guessing GP has worked with some bad developers who cargo culted GoF and name checked them for all manner of bad ideas. So it goes…


Honestly no shade on the actual book or authors, but my heart sinks every time I see a dev reading that book, because I _know_ some truly bad ideas are coming down the pipe really soon.

Ironically, none of those ideas the dev then starts pushing are ever "Prefer composition over inheritance" which is literally a section in chapter one.


I keep failing to write that test that would make the UI/UX acceptance criteria valid, if somehow I could do integration tests with Adobe XD.


Would you be kind and expand a bit on "snake oil salesman" in connection to unclebob? Thank you!


This article[1] also explains some complaints.

1: https://qntm.org/clean


From the comments of that article:

I reread your breakdown of the FitNesse code example a few times and I felt less and less generous about the analysis each time. Here's two and half questions:

1) If private fields are NOT to be considered implicit arguments to every private method, what exactly are they for? (And if they should not be modified, why would they be anything other than 'final'?)

2) Why do you consider Martin's definition of side-effect, which speaks of 'global state' and 'unexpected changes' to include changes to private members of the class in functions that document those changes via their signature?

You could answer those uncharitably and make Uncle Bob look bad, or you could answer them charitably and then his code makes sense.

I also have to say I don't understand how 'illegible trash' is remotely an appropriate description. This is as good as just about anything I've seen in actual production work in 10 years. It's extremely readable and quite testable. There are nits to pick (and you've done an excellent job of that), but for some part of those at least I feel like they're to be picked with 2008 Java API and coding standards rather than the author.

I can't see that reading this book would be a net negative for 95% of people writing OO code. If you also don't know of a better book either, I'm stumped as to why you'd stop recommending it.

Finally, it looks to me like there's people out to get Uncle Bob cancelled for not being on-board with a certain political invasion of software that's going around at the moment (you can already see a comment calling him 'a terrible human'), so I'm somewhat suspicious of ulterior motives here. If that's not your intent, my apologies.

I did like this article in general and found it to be plenty insightful, so I'd love to read more from you.


Funnily enough, I don't think the quoted comment makes a charitable interpretation of the article.

> Why do you consider Martin's definition of side-effect, which speaks of 'global state' and 'unexpected changes' to include changes to private members of the class in functions that document those changes via their signature?

In Martin's definition, the first example of a side effect is "unexpected changes to the variables of its own class". Perhaps the argument being made here is that the changes aren't unexpected, but in that case, the article is very clear in that it considers them unexpected.


I have also been writing software for a while, and I agree with most of Martin's claims that qntm sites in that article. But I also agree that the example code is utter crap. It violates most of the rules that Martin just gave in the chapter.

Now, having written technical documentation myself, and even "Welcome interns" docs, I understand that writing good examples of good code is quite hard. But on the other hand, if one is writing a book about good programming then take the time to write examples that actually demonstrate what was claimed in the preceding pages! Like, it would be better to have a comment saying "Imports elided for brevity and printing costs" rather than writing wildcard imports.


It might be that the claims of Uncle Bob are pseudoscientific, they don't have any support, neither in science, nor in real life?


Pretty much this. He pontificates from a position of authority that has nothing to back it up.


"Pontificating from a position of authority with nothing to back it up" is what every thought leader does though; it's practically a requirement for amassing "influence" as everyone calls it.

Why does Uncle Bob get a larger amount of ire?


In the Karate Kid, the Karate Expert Mr Miyagi teaches youngster Daniel the martial art of Karate. My Miyagi begins by having Daniel paint his fence and wax his car. Daniel doesn't understand how this helps, and has a tantrum, at which point Mr Miyagi demonstrates that Daniel has, in fact, been building the muscles and reflexes necessary for Karate.

They situation here is simply one where Daniel is not qualified to evaluate Mr Miyagi's methods. Conversely, had Daniel the necessary experience to evaluate the method, he would not have needed instruction.

The internet is full of Daniels, and gives them the ability for their tantrum to reach a large audience. The internet is far more full of Daniels than Miyagis. Further, to tell the difference between a Daniel and a Miyagi, one has to be a Miyagi (see Dunning, Kruger).

Finally, there are legitimate differences in approach between different masters. Sensei John Kreese has very different methods compared to Miyagi, that are, nevertheless, clearly effective. Kreese also has turned his experience into a business and this influences his decisions, such as breaking agreed rules.

Bob might be Miyagi, and he might be Kreese. Most of what he says is good advice, in my opinion. Some of it isn't. Which parts are which depends on who you ask. But most of the complaints come from Daniel.


Agree. I always suspected that Daniels are everywhere with the fact that few people wish to talk seriously about software, instead preferring to talk about fashionable software.

Bob also speaks highly of teaching developers to design software well. This is unpopular right now, we prefer to believe that tools alone are all we need.


Authority and influence are conflated here, especially where you understand authority as expertise (i.e. an authority on a topic). Such an authority should be able to produce credible evidence in support of their claims, else they are possibly not an authority in this sense.

The implication of your question though, is that you do not think Uncle Bob is an authority in this sense, merely an influencer?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: