DEV Community

Discussion on: The ONE chart every developer MUST understand

Collapse
bosepchuk profile image
Blaine Osepchuk Author

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.

Collapse
mbjelac profile image
Marko Bjelac

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:

  • requirements are properly analised and backed by examples
  • every feature has an automated "done" flag which devs can use to know when the feature is implemented
Thread Thread
bosepchuk profile image
Blaine Osepchuk Author

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.