|
in reply to Test Driven Development, for software and for pancakes
7 Reasons Why TDD Failed to become Mainstream.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
Suck that fhit |
Re^2: Test Driven Development, for software and for pancakes
by talexb (Chancellor) on Jul 23, 2017 at 16:30 UTC
|
Interesting -- however, just because this headline claims that it failed to become mainstream, doesn't mean it's not a useful methodology.
Let's look at the list on this page.
- TDD is Expensive / There may be an additional time cost, but I believe there's also an increase in the quality of the final product.
- TDD Will Retard Your Project Launch / This depends; if you have a hard date for your launch, then TDD may cause you to launch with a slimmer product.
- You Will Change Your Projects and Old Tests Become Waste / Perhaps some top-level tests will be invalidated as the project changes, but I would imagine that the lower level stuff code and tests would continue to be useful.
- Testing the Means is a lot more Work Than Testing the Outcomes / I would rather have decent tests all the way up the food chain, than having something at the end that says Go/No Go with no idea where the issue might lie.
- Extensive Testing is Boring / Sure, sometimes developing software is boring. However, if you bounce between writing tests and code, I don't imagine that would be boring for long. Writing documentation for two weeks straight is something I did recently that was a little boring -- but necessary -- for the contract I'm on right now. I wouldn't be happy if I were doing it full-time, but for me it's come after four months of development. So I'm OK with that balance.
- Many TDD Preachers Do Not Use it Most of the Time But Do Not Admit it / This sounds anecdotal to me -- to each their own.
- Many Reputed Developers Do Not Use TDD at all / Another anecdotal claim. The reputed developers may have good enough levels of craftmanship that they don't need tests. I'm happy to use tests myself when I develop software, as it gives me confidence in my code.
And it's good to also read in this article that TTD is not dead. I think it's still a valuable development methodology.
Everything Has to be an Object, however .. ugh.
Alex / talexb / Toronto
Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.
| [reply] |
Re^2: Test Driven Development, for software and for pancakes
by Arunbear (Prior) on Jul 24, 2017 at 09:57 UTC
|
| [reply] |
|
|
| [reply] |
Re^2: Test Driven Development, for software and for pancakes
by karlgoethebier (Abbot) on Jul 24, 2017 at 15:51 UTC
|
Thanks for sharing the cool link. I never really used TDD but anyway - some thoughts: Let's say you want to write a chess engine. You start with the board representation. This is quite tricky. Robert Hyatt needed years to understand how to accomplish this. Nowadays these techniques are less or more well know, but you still need a mistakeless representation. Isn't something like this a use case where you are lost without TDD?
My 2˘ about the other manias:
- Everything Has to be an Object: No
- Forcing Yourself to Use as Many Design Patterns As Possible: No
- Argue Over Code Formatting Styles: Yes. Always in style
- Programming has to be Beautiful: Yes. Even the dishes i cook are so (but perhaps my programs are not)
- Hire More Developers to do Pair Programming: Yes. I did just a handful of jobs using it but this were my best projects ever
Best regards, Karl
«The Crux of the Biscuit is the Apostrophe»
perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help
| [reply]
[d/l] |
|
|
but you still need a mistakeless representation. Isn't something like this a use case where you are lost without TDD?
I really fail to see why you think that particular example is amenable to TDD, or unamenable to any of the other non-test-driven development methodologies?
Nor why a game's internal data representation should be any more "mistakeless" than that of an automated drug dispenser, or a traffic control system, or fingerprint matching algorithm?
But as you've chosen that example, here's a little thought experiment for you. You are charged with writing a replacement board representation: write your first test.
Chances are, you simply haven't a clue where to start; and you'd defend that by saying that you need a specification.
But how do you write a specification for something you have no idea how to write? So maybe you read this (if you haven't already). So, now you know a little about the possible representations and requirement of them, so write that first test. Once again you (probably) cannot.
One thing I can guarantee, Robert Hyatt didn't use TDD back in 1968, and -- having read a few of his papers -- I doubt that, even given his 50 years of experience and knowledge, that he used it when they switched from rotated bitboards to magic moves circa 2004.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
Suck that fhit
| [reply] |
|
|
| [reply]
[d/l] |
|
|
