ANTIDOGMA
summary
Examines common software-development dogmas—like TDD being always best, screenshot testing being too costly, everyone needing to be full‑stack, or teams always deploying their own products—and argues that these practices can be appropriate in some project contexts and harmful in others. Reviews core development practices and extracts the contextual nuances that determine when each technique is useful, advocating abandoning rigid dogma.
AI-written summary · about
chapters (13)
- 0:00Welcome
- 2:27What is a dogma?
- 9:57Dogmatism in learning
- 12:06Fighting dogmas
- 16:38Right to mediocrity
- 22:58Tests as tools
- 25:08Dev branches and environments
- 30:49Inclusive pair programming
- 37:56Tools and context
- 41:52Senior responsibility
- 45:04Dogmas and marketing
- 51:07Diversity and mediocrity
- 53:53Conclusion
related talks
05mEngineering Without Dogma: When to Ignore the Best Practices
46mGood practices — why are they good?
46mHow to fall in love with TDD
22mDo We Need Software Craftsmen?
27m'The Art of Software Development'
43mTDD: when to use it and, most importantly, when not to
47mValue: Why we have it Backwards
46mIt’s XP Stupid!