Scary thought: maybe those who say they can't do TDD are right

Discussions

News: Scary thought: maybe those who say they can't do TDD are right

  1. Tim Ottinger, from Object Mentor, says in "What can't who do?," that "When someone is supposed to change their workstyle to do TDD, and they say 'we can't do that,' how about we assume they're telling the truth?" He then deconstructs what the statement might mean... and ends up pointing out that there may be a misconception on someone's part about what test-driven development is.
    The first word is "we." It may well be that the speaker and the people he represents might not be able to do the work. They're not saying that it can't be done. They're only saying that they can't do it. The next word is "can't" and that's an interesting word, too. It might mean that they lack the ability or knowledge. That's ideal, because such things can be taught and can be led. The other sense is that they are not allowed. If it's like that, then there is going to be some political work going on. But at least you know what you’re getting into. The other tell is the word "that." Maybe they should describe what it is that they can’t do, and you can tell if the thing they can't do is the same thing that you are wanting them to do. Sometimes it is not.
    Tim has three good points - figuring out exactly what the statement means allows you to target what barriers there are to TDD in an organization. Of course, all this assumes that you see TDD as a good thing... [Editor's note: Tim Ottinger is no relation to Your Humble Editor - our last names are the same, but as far as we know there's no familial tie. We've talked about it briefly before. For myself, I'm glad there's at least one good writer with our last name - and I mean him!]

    Threaded Messages (15)

  2. Irrelevant[ Go to top ]

    So what is he saying. That someone might do something somewhere instead of someone else not doing something else? That's what I call a revolutionary insight! Oh and one more thing "It might mean that they lack the ability or knowledge." sounds quite arrogant, because a lot of people who have embraced TDD have turned away from it again, because it did not work out for them. Now, it might well be that a certain development style might not be applicable in a certain *business* environment.
  3. Examples of TDD turnaway[ Go to top ]

    a lot of people who have embraced TDD have turned away from it again, because it did not work out for them.
    Can you elaborate on this comment? Can someone tell me the approximate percentage of those that embraced it, but have turned away from it? And why they turned away from it?
  4. Re: Examples of TDD turnaway[ Go to top ]

    Can you elaborate on this comment? Can someone tell me the approximate percentage of those that embraced it, but have turned away from it? And why they turned away from it?
    I have seen a number of projects / project teams, where TDD was advocated yet after a certain time, it turned out to be infeasible. There were various reasons, but I will try and give a few. - Meaningful tests required very extensive test harnesses. - A tendency evolved to test the trivial, even with high code coverage. - People simply refused/forgot to write tests (no you couldn't fire them :-(). - Especially with partly finished products, moving to TDD like development can be an overwhelming effort - this is dodged in particular, if people know that the testing will not come out favourably. - Business was not able to provide decent specification and interaction.
  5. Can you elaborate on this comment? Can someone tell me the approximate percentage of those that embraced it, but have turned away from it? And why they turned away from it?


    I have seen a number of projects / project teams, where TDD was advocated yet after a certain time, it turned out to be infeasible. There were various reasons, but I will try and give a few.
    - Meaningful tests required very extensive test harnesses.
    - A tendency evolved to test the trivial, even with high code coverage.
    - People simply refused/forgot to write tests (no you couldn't fire them :-().
    - Especially with partly finished products, moving to TDD like development can be an overwhelming effort - this is dodged in particular, if people know that the testing will not come out favourably.
    - Business was not able to provide decent specification and interaction.
    1 - Meaningful tests required very extensive test harnesses. Isn't this a problem of understanding what kinds of testing belong in a unit test and what kinds of testing belong in an integration test or UAT? 2 - A tendency evolved to test the trivial, even with high code coverage. 3 - People simply refused/forgot to write tests (no you couldn't fire them :-(). These are just matters of education and working practice surely. I'm sure similar problems were encountered when trying to get C programmers programming in C++ to use OO concepts. (you couldn't fire them either!) 4 - Especially with partly finished products, moving to TDD like development can be an overwhelming effort - this is dodged in particular, if people know that the testing will not come out favourably. I agree, sometimes TDD is not applicable 5 - Business was not able to provide decent specification and interaction. But surely at least some of the value of a test case suite is to give you some certainty as to how your application behaves regardless of whether a business person has told you how they want it to behave. If you don't think this has value without a business spec does that mean you think that a functional spec has no value either? For me TDD simply formalises your expectation of how your app should work. On a project where those assumptions have not received an official sanction from the users at least the point of reference is still there. It's better to not know what people want your code to do, but know what it does, rather than to not know either.
  6. Up with arrogance[ Go to top ]

    Oh and one more thing "It might mean that they lack the ability or knowledge." sounds quite arrogant
    If postulating about one possibility rather than declaring it to be unequivocally so is arrogant, then may we all be so arrogant. It sure beats making assumptions about the speaker.
  7. Re: Up with arrogance[ Go to top ]

    Oh and one more thing "It might mean that they lack the ability or knowledge." sounds quite arrogant


    If postulating about one possibility rather than declaring it to be unequivocally so is arrogant, then may we all be so arrogant. It sure beats making assumptions about the speaker.
    Quite right. But can't usually does not refer to the ability or knowledge. There is plenty of literature available on the subject and "can't" usually refers not to "ability and knowledge" but to matters in project organization, delivery organization, business interaction etc. that can be very profound reasons not to use TDD.
  8. Re: Up with arrogance[ Go to top ]

    Oh and one more thing "It might mean that they lack the ability or knowledge." sounds quite arrogant


    If postulating about one possibility rather than declaring it to be unequivocally so is arrogant, then may we all be so arrogant. It sure beats making assumptions about the speaker.
    I'm detecting some arrogance in the original statement as well. I can see a third reason why they say "can't": maybe they *really* can't. It's just not technically feasible. Or so hard that it's just not worth it and you're better off leaving a human in the QA department test it. Examples? How about a Java ME application? (or more simply, a UI-driven one) Most developers do *no* TDD at all. It's about time we started listening to these people instead of trying to lecture them. -- Cedric
  9. Re: Up with arrogance[ Go to top ]

    Most developers do *no* TDD at all. It's about time we started listening to these people instead of trying to lecture them.

    --
    Cedric
    Yes! Testing is for suckers.
  10. I agree they are right[ Go to top ]

    The next word is "can't" and that's an interesting word, too. It might mean that they lack the ability or knowledge. That's ideal, because such things can be taught and can be led. The other sense is that they are not allowed. If it's like that, then there is going to be some political work going on. But at least you know what you’re getting into.
    After quite some time advocating TDD I've realized that although the vast majority of software developers understand technically how a test such as JUnit is written, they really don't get TDD. It is very rare that I write something and am unable to test it. The code is structured from the ground up to be testable. I've found a tendency for folks to write the code the way they want to, then reflect that it cannot be easily tested. It's really a painful process mentoring in this case, because you're really trying to fundamentally change how someone codes and that's a tough sell. I'd say in my experience maybe 30% of the people will get it, recognize how much faster they are because their code passes QA more quickly, they can refactor more quickly, their code naturally becomes more reusable (since it's already reusable enough to support a test), etc. The rest of the folks write tests but do so as an after thought and only write them to satisfy the goal of writing them.
  11. Carts and horses[ Go to top ]

    I don't want my team's D to be driven by T at all. I want my team's D to be driven by customer desires. Creating tests before creating code, now that's a different thing. Which has to be a good idea, up to the point where it costs more to create tests than to test code. But we already knew that ...
  12. There was an interesting interview (on Artima?) with two people behind a Ruby testing approach. They had avoided the term TDD in favour of "Responsibility-Driven Development", and not just out of a desire to be contrary. They argued (quite persuasively, IMHO) that the focus on *tests* was misleading, because it focused on the wrong thing. Instead of thinking "how do I test this", you want developers to think "what should the responsibilities of this object/method be?" and then write tests that confirm that it carries out those responsibilities correctly. I think this is the mindset shift that people who 'get' TDD are able to make subconsciously, but which eludes many others. Told to focus on tests, they resist the idea (for a number of reasons) and so never do TDD long enough to have the "aha" moment when the suddenly realise that "it itsn't about tests, per se, it is about identifying correct behaviour, and then thinking of a way to detect incorrect behaviour!" Put it to them like that--as a two-step mental process--and we may see the lights go on for many more people. God knows it took me several days of struggle to 'grok' TDD, and it wasn't until I heard the Ruby guys talking about 'RDD' that I realised why it was so hard, and how I'd finally overcome it. Cheers, Christopher
  13. Strange enough. Noone suggesting SDD (Skill ...) ? I still think that the best tool on the market stays few inches above your neck. Please checkout the following articles from Douglas Schmidt http://www.cs.wustl.edu/~schmidt/editorial-0.html http://www.cs.wustl.edu/~schmidt/editorial-5.html and this from Michi Henning http://www.zeroc.com/newsletter/issue22.pdf Guido
  14. Strict TDD may never work[ Go to top ]

    There have been many suggestions in this thread as to why TDD may not be suitable. One of the best I read (and experienced) is the fact that often requirements are patchy and changing. I also think that concentrating too much on the test upfront (or Responsibility as someone else called it) may lead to the wrong test, the wrong design or both. In my opinion, the problem lies in trying to be too strict about TDD. I prefer a more relaxed mode where an initial design is layed out as a set of interfaces, followed by some tests to drive an initial implementation. Then I let the implementation shoot ahead for a while with unit tests following and occasionally taking over again (back to TDD). The idea is not to lose sight of the bigger picture by focusing too much on a small piece of the whole system. It can be expensive to rewrite large parts of the API if that also means rewritting all those tests (could this be the reason some people abandoned TDD altogether?).
  15. "Maybe they should describe what it is that they can’t do, and you can tell if the thing they can't do is the same thing that you are wanting them to do. "
    We have delivered a J2EE web application just recently with lots of image processing involved. The testing of the application required visual inspection of the images that are being painted through the web browser. There is no possible way TDD can fit in here, when even the unit testing of the application requires tedious masking of images, positioning them in an applet and gamut of other visual features apart from the server-side logic. IMHO,just bluntly summarizing that "TDD is the only approach" is not politically correct. Everyone should respect every school of thought out there and not try to force their ideology on the whole enterprise community. I have worked on lots of financial applications where TDD makes sense as the use cases and unit tests could have been concretely summarized. We can definitely not make TDD the ideal approach to follow in case of every application out there. We should obey our common-sense when required.
  16. No silver bullet?[ Go to top ]

    Gosh ! Maybe there is no silver bullet ... Having said that, things should be designed with testeability (sp?) ... UIs are not easily testable because they did not care to design UI Kits that way ... Moving requirements is a big marker for striving for TDD (as tests are "a bit" more evaluable than written specs). DbC(TM?) is also a good idea, but not everybody has the luxury of working with clear contracts ... Now, moving requirements, non testable building blocks, non clear contracts ... So, what field that builds things could have all those in a high grade and not suffer? Sometimes, I'm amazed why things do not fall apart more often :)