5 ms·

Uncle Bob, dazed, comes out swinging. Struggles to land punches, but DHH definitely has Bob's attention. There are cost/bene's for unit tests. There are cost/b

by pistle 12y ago

Uncle Bob, dazed, comes out swinging. Struggles to land punches, but DHH definitely has Bob's attention. There are cost/bene's for unit tests. There are cost/bene's for integration, etc. etc. etc. Cargo cult behavior and adherence gets you to where DHH makes his statements. Inexperience with Uncle Bobology leaves you unable to cogently decide upon structuring effective, manageable tests. Clients' and consumer unwillingness to pay up for tests that increase LoC by factors of 2+ mean devs need to be effective at balancing the ship cadence and the overhead of tending the test base. You can't blindly accrue meaningless or value-little tests. You can't always just refactor code written to be ultimately testable. Uncle Bob seems to pretty much only talk about tests. DHH made a larger argument about the practicality without merely expressing simple boredom or uninsightful consideration of the value of testing. 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.

raverbashing 12y ago
"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.
- kasey_junk 12y ago
  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.
  - raverbashing 12y ago
    Not so much him, but the ones who repeat what he says as gospel.
    - kasey_junk 12y ago
      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.
      - raverbashing 12y ago
        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.
        nnq 12y ago
        > 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" :) )
        12y ago
- visural 12y ago
  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.
  - raverbashing 12y ago
    I agree with you, just a note, "practical pragmatism" is a pleonasm http://en.wikipedia.org/wiki/Pleonasm http://en.wikipedia.org/wiki/Pleonasm
- chadcf 12y ago
  > 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.
  - raverbashing 12y ago
    "The lack of understanding that different people, projects, languages, frameworks, companies, etc may require different strategies" This is the right answer.
bsnape 12y ago
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.
- dasil003 12y ago
  > 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.
pjmlp 12y ago
> 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.
- humanrebar 12y ago
  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.
  - pjmlp 12y ago
    > 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.
    - humanrebar 12y ago
      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.

by pistle 12y ago

raverbashing 12y ago

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

kasey_junk 12y ago
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.
- raverbashing 12y ago
  Not so much him, but the ones who repeat what he says as gospel.
  - kasey_junk 12y ago
    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.
    - raverbashing 12y ago
      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.
      - nnq 12y ago
        > 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" :) )
      - 12y ago
visural 12y ago
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.
- raverbashing 12y ago
  I agree with you, just a note, "practical pragmatism" is a pleonasm http://en.wikipedia.org/wiki/Pleonasm http://en.wikipedia.org/wiki/Pleonasm
chadcf 12y ago
> 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.
- raverbashing 12y ago
  "The lack of understanding that different people, projects, languages, frameworks, companies, etc may require different strategies" This is the right answer.

bsnape 12y ago

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.

dasil003 12y ago
> 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.

pjmlp 12y ago

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

humanrebar 12y ago
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.
- pjmlp 12y ago
  > 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.
  - humanrebar 12y ago
    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.