> Which makes me question Uncle Bobisms, because it reeks of lack of practical experience.

The thing people need to realize is that these two come from very very different worlds. Sure, Uncle Bob may pale in experience compared to DHH when it comes to agile rapid development of simple opinionated SaaS apps, however he has a world of experience in handling large enterprise application development.

I think this leads to their different take on the issue here, because how software is developed in these two different environments is very different. Which is why I tend to think what DHH advocates works very well for what DHH does, and what Uncle Bob advocates works very well fro what Uncle Bob does.

The lack of understanding that different people, projects, languages, frameworks, companies, etc may require different strategies, tools and techniques is what frustrates me about this whole argument more than anything. I suspect most of us developers lie in the middle ground between this extremes and rather than focusing on which method we should 100% follow, it is perhaps best to pick and choose things from each position that we find helpful to our own practice.

"The lack of understanding that different people, projects, languages, frameworks, companies, etc may require different strategies"

This is the right answer.

I think you used the wrong word - IMO Uncle Bobisms often show a lack of practical pragmatism. The vibe I usually get from listening to him is along the lines of... "if everyone just did things the right way then we wouldn't have all these problems", which is firstly, not a realistic point of view, because there is no reality where every developer on a team is going to do everything the same way, let alone one person's idea of the "the right way", and secondly it's just unprovable conjecture that these things would solve all our problems in the first place.

I'd rather listen to people with a proven track record for shipping great software and a history of reasoned pragmatism regarding techniques and methodology.

I agree with you, just a note, "practical pragmatism" is a pleonasm http://en.wikipedia.org/wiki/Pleonasm

I think that there are lots of ways you can criticize Uncle Bob, this article, his works etc. But saying he is inexperienced is a pretty big stretch.

Compared to someone like DHH, Uncle Bob has very little practical experience. Even without comparing him to DHH, there is hardly anything that we can look at to measure Uncle Bob's experience besides Fitnesse (which is a very, very messy code base).

On top of that, Uncle Bob has a vested financial interest in TDD because he's a consultant who makes money off it.

Finally, Uncle Bob has a history of claiming things without backing them up and just expecting the world to believe him. "TDD is the only way to write good software" is one of these claims that is finally being challenged.

It's about time.

"Compared to someone like DHH, Uncle Bob has very little practical experience."

Are you even joking?

Bob Martin starting programming about 45 years ago, 9 years before DHH was even born. I remember having discussions with the man about software design almost 20 years ago on USEnet when I was in college. The dude has being doing this stuff for a long, long time. He wrote THE book on object-oriented design principles. He was one of the original Agile guys. You can't just look to open source projects as a judge of someone's output over decades, Github didn't even exist 6 years ago.

DHH is using strong language to make people think about aspects of TDD that have gone awry. Just as Bob uses strong language to make people think about testing. The intent was to foster a debate, which has worked. This won't mark the end of TDD, just rethinking about how far we design our code for testing.

You are confusing "Having been around for a while" with "Having practical experience". Uncle Bob has been a consultant for a very, very long time and living off articles, presentations and books on the topic of software engineering. He has much more practice talking and consulting about these things than actually writing code in the industry.

Bob is a consultant who codes, and coaches those who code, and has a long track record of doing so.

Not only are you making an ad hominem argument, you're completely discounting the experience of one of the giants of our field. Only HN.

Not that I think that ad hominem attacks are a good way to settle this particular debate, but most of what you are complaining about can be directly applied to DHH as well. That's the nature of ad hominems. They don't really get to the heart of the problem.

Not so much him, but the ones who repeat what he says as gospel.

You are also trying to associate TDD with religion in an attempt to make it seem bad. This is one of the criticisms in the posting and it seems sort of fair.

And then he ends with the phrase " If you aren't doing TDD, or something as effective as TDD, then you should feel bad."

NO

People should feel bad for wrong things, not by not following some methodology.

This is what cults and religions do, they make you feel bad for not following what they preach.

So yeah, if you don't want to be associated with a cult, don't act like one.

> or something as effective as TDD

this is the important part of the sentence: he's actively admitting that TDD may not be the best thing, but it's the best thing he knows, but if you have something else that is at least "as effective as TDD", than go ahead and and to the other thing. He just means that, paraphrasing, `you should feel bad if you are not being as effective as possible, and TDD is the only way I know of of being so effective`.

"Uncle Bob" seems like a pretty open minded guy, but his communicative style make lots of people really misunderstand what he says. DHH otoh is very good at sending his message across to "high energy" type of people that want a "strong punch" and don't have time to carefully read every word of an argument and digest its meaning... this is probably your "type", so this is why you like DHH's message more, but both are smart guys and both of their arguments are valid in different contexts :)

(and generally speaking, I think "Uncle Bob"'s advice is more valuable to mediocre programmers than DHH's, as it imposes a mindset that limits "the damage one can do" :) )

You need to read that statement a bit closer.

" If you aren't doing <a method to verify quality day-to-day work>, or something as effective as <a method to verify quality day-to-day work>, then you should feel bad."

The point is that if you're not doing TDD, you should be doing something that's as effective (or more) as TDD. Otherwise you're just doing shitty work.

IOW, you can disagree with Bob about TDD being the most effective way to verify quality, but you still need to verify quality.

I'm not sure about you, but I think people that do shitty work should feel bad. That's not cultish, that's just basic professionalism.

People have been verifying software since software was created.

Manual verification is indeed more complicated, slow and prone to failure but it's not worthless as the TDD people paint it, not TDD is the holy grail (it has a lot of deficiencies that seem to be ignored by the TDD people)

Also, UBob is lashing other testing DHH proposes in the text, but guess what, it's meant to test what TDD doesn't reach.

You can have 100% coverage of your tests with TDD and still have a bug.

"Manual verification is indeed more complicated, slow and prone to failure but it's not worthless"

Manual vs. automated is a whole other discussion, rather separate from TDD.

Manual test scripts are not worthless, but are certainly an indication your project is either (a) very small scale or simple or (b) going to take a very long time to complete and be prone to regressions.

TDD is about the benefits derived when you write your test case before your code, and also the design implications of doing so.

"You can have 100% coverage of your tests with TDD and still have a bug."

Obviously. But the probability of your codebase having defects goes down drastically with higher code coverage.

You could take the new radical approach of "don't test, just ship", but that requires a very specific organizational culture and risk profile.

He's saying that you need some way to verify that what you have done works as advertised. I agree.

I've seen this behavior from both the Uncle Bob and DHH camps. Then again, how many Rails devs out there are using Rspec or alternative Rails stacks?