Writing Code That Doesn't Suck

Buzzwords like BDD, TDD, ATDD, RDD, and DDD may have convinced you that writing great, maintainable code is just a matter of following a few simple instructions. All you need to do, you've been told, is write good unit tests, and make sure you have a good CI suite to call you out when your tests fail.
Following the zealotry of the day will leave you with brittle and vulnerable tests after every refactor. You will write coupled code and expose far too much implementation detail to consumers of your code. This is exactly what happened with Merb 0.5, which was almost feature-for-feature compatible with Merb 1.0, but with a mishmash public API that made it very difficult to detect the breaking changes we introduced.
Beginning with Merb 0.9, we took a radically different approach, focusing almost entirely on the public interfaces we were exposing. We made sure that our tests covered those interfaces, not merely the individual methods that were being run. Along the way, we learned lessons about testing, writing code to be used by others, loose coupling, public interfaces, and a whole lot more.
Join me as we examine some of those lessons, using Merb as a lens. We'll be challenging many orthodoxies of today's Ruby programmers, so if you fear change, stay away. On the other hand, if you're looking for some new ways to think about writing complex systems, testing them, and making your tests resilient to even the most invasive refactoring, join me. Let's step through the looking glass together.

Videos are in h.264 quicktime format. We recommend Miro for viewing these files.