Hacker News Reader

"UBob doesn't even tread into the crux of the matter, which is that code style and system architecture bent to the needs of testing becomes a ball of mud (though "testable") faster than code written without this consideration."

Exactly that

Which makes me question Uncle Bobisms, because it reeks of lack of practical experience. DHH shipped a framework that's used by several people, providing value.

The best measure of software is value to the user. However, some people think software is meant to have the nicest structures, the greatest coverage, etc. Which are nice things to have but they come after (in matters of importance, not in time) shipping a software that solves the user problem.

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.

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" :) )

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

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.

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?

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.

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.

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.

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

> 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.

> UBob doesn't even tread into the crux of the matter, which is that code style and system architecture bent to the needs of testing becomes a ball of mud (though "testable") faster than code written without this consideration

Not to mention that GUIs, algorithms, stored procedures and a lot more other types of architectures are impractical to write, if at all, using TDDs approaches.

I never saw a way that could convince me to use it in such cases.

I'm with you on testing GUIs and (mostly) stored procedures. I would add low-level interfaces (hardware, OS, third-party library implementations) to that list.

Algorithms are certainly testable with TDD though. In fact, they're probably the easiest thing to test. Maybe I don't understand what you mean by algorithm, but things that can be expressed mathematically (sorting, searching, decision trees) are very straightforward to test. Tests can even be reused to verify multiple algorithmic approaches to the same problem.

> Maybe I don't understand what you mean by algorithm ...

I mean using TDD to specify:

- memory layout of the internal data structures

- O() access times

- cache friendliness

- concurrency

I see how one can test them in a unit test approach with whiteboard design and such, but not in a "write test, fail, write code, success" cycle that is usually sold on conferences.

Unit testing would let you validate the correctness of the code.

As far as improving performance characteristics, the argument is that unit testing helps indirectly by improving awareness of the behavior of your system. Having a good idea of where there aren't bugs will let you be more aggressive in refactoring to improve things like performance characteristics.

Sun Tzu:

If you know your enemies and know yourself, you will not be imperiled in a hundred battles... if you do not know your enemies nor yourself, you will be imperiled in every single battle.

...if it's not clear, you are your code and bugs are enemies. It's all about mitigating risk through better understanding of your code base.

TDD doesn't preclude one from doing whiteboard design and thinking things through. It just asks that you write a test case before you write your code.

It's sort of like enabling the feedback of a REPL to any language. Why wouldn't you write a test case to test the O() access time of a function ahead of time? Or test the memory layout of a data structure?

Seems to me those are great examples of tests I would write to help me flesh out the results I want, before I go and implement it. They help one specify _exactly_ what they want.

> Why wouldn't you write a test case to test the O() access time of a function ahead of time?

Because asymptotic limits are a lot easier to verify analytically than empirically. You can, of course, easily test the actual performance characteristics under specific conditions, but that's different than testing the asysmptotic limit.

Of course, TDD doesn't preclude analytically verifying those things that can be analytically verified.

Testing algorithms is easy, yes, but it's usually not clear that TDD would lead you to design the optimal algorithm.

It would not, but good tests will let you verify the correctness of the algorithm without deploying your software to customers. Which frees you up to try more experimental things without ruining the experience of the users.

If DHH's main concern was practicality he wouldn't advocate UI & DB tests which are flaky, unreliable and expensive to maintain for any non-trivial application.

Code and system architecture absolutely should be bent to the needs of testing. Pretty and "clever" code is useless unless it does what it's supposed to do.

UI & DB tests absolutely have their place - I'm not disputing that at all, and I completely and whole-heartedly advocate their use - but they need to be used in conjunction with very fast, very reliable (and thus very useful) unit/integration tests that have been TDD'd.

> Pretty and "clever" code is useless unless it does what it's supposed to do.

Except DHH is not advocating 'pretty or "clever"', he's advocating readable and comprehensible code. I think it's unfortunate for you to put this trumped up straw man in the middle of an otherwise cogent argument.