I come to the same conclusion but from a slightly different angle (even including the developer-in-crappy-company problem): dev.to/mbjelac/stop-the-madness-14f6
As a TDD enthusiast I particularly found interesting your mention that testing (after development) is largely ineffective, contrasted to test-prevention techniques (TDD included) which are not.
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
I read your links and I largely agree. I've seen lots of articles like Fowler's. They make their case with logic and appeals to common sense, which is okay but I wanted my article to be backed by data. It took a while to find these books and it took even longer to read them but I'm happy with the results.
Depending on exactly what you meant with your TDD comment, I don't think the authors of either book would readily agree. If you have a low quality development process on two teams and one team does TDD and the other team writes their tests after they write their code, you probably won't see much difference in the quality of the final product. It will be low in both cases. After all TDD won't catch requirements errors, which account for about 60% of the delivered defects in most projects.
But TDD could be a beneficial component of an overall quality program that stresses defect prevention and early defect detection and removal. That kind of development strategy will likely produce higher quality software than a team that focuses on a more informal development process and then hopes to find and fix defects to drive quality into their project at the end.
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
I'd assume micro-level TDD as well but the authors didn't specify. BDD existed in 2011 (when the book was published) but just barely and it wasn't very popular yet.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Excellent article!
I come to the same conclusion but from a slightly different angle (even including the developer-in-crappy-company problem): dev.to/mbjelac/stop-the-madness-14f6
An article I reference is Martin Fowler's Is High Quality Software Worth the Cost? which discusses the very same topic as your article.
As a TDD enthusiast I particularly found interesting your mention that testing (after development) is largely ineffective, contrasted to test-prevention techniques (TDD included) which are not.
Thanks for this great article!
I read your links and I largely agree. I've seen lots of articles like Fowler's. They make their case with logic and appeals to common sense, which is okay but I wanted my article to be backed by data. It took a while to find these books and it took even longer to read them but I'm happy with the results.
Depending on exactly what you meant with your TDD comment, I don't think the authors of either book would readily agree. If you have a low quality development process on two teams and one team does TDD and the other team writes their tests after they write their code, you probably won't see much difference in the quality of the final product. It will be low in both cases. After all TDD won't catch requirements errors, which account for about 60% of the delivered defects in most projects.
But TDD could be a beneficial component of an overall quality program that stresses defect prevention and early defect detection and removal. That kind of development strategy will likely produce higher quality software than a team that focuses on a more informal development process and then hopes to find and fix defects to drive quality into their project at the end.
Cheers.
I agree with your view that TDD alone isn't enough. I suppose that by TDD you mean unit (micro) level TDD.
I use the term more broadly to include the BDD process - a form of requirements gathering which ensures (at least) that:
I'd assume micro-level TDD as well but the authors didn't specify. BDD existed in 2011 (when the book was published) but just barely and it wasn't very popular yet.