Les Hatton theorizes the possibility to predict the number of defects in software systems based on the observation that such systems have properties independent of why, how or who implemented them.
Ahmed Syed explains how to use testing and defect management in an Agile project to ensure product quality, addressing design quality, legacy systems, and how build management affects quality.
Ulf Wiger shows typical Erlang programs, patterns that scale well on multicore and patterns that don't, profiling and debugging parallel applications and ensuring correct behaviour with QuickCheck.
Developer-driven testing is probably the most influential software development technique of the last 10-15 years. There's no question that it has improved the practice of building software. And in a dynamic language like Ruby, it's hard to get by without it. But is it really the best way to find defects? Or is the emphasis on testing and test coverage barking up the wrong tree?