RailsConf 2014 - Keynote Writing Software by David Heinemeier Hansson

Help us caption & translate this video!http://amara.org/v/FG1c/

• 14:03: If all of your Heroes are unrelatable then that's a problem.
• 23:54 TDD is criticized as the "most popular pattern for making people feel shitty about their code and shitty about themselves and shitty about their path through programming."
• 24:23 TDD is described as the "most successful software diet of all times," with the allure that "all software before TDD was shit and unprofessional."
• 25:02 personal struggles with TDD, feeling it didn't lead to better or cleaner code, despite the pressure to adopt it.
• 26:06 TDD is framed as a "great diet" because it keeps people in a "perpetual state of feeling inadequate," leading them to seek more books, talks, and consultants.
• 27:41 The speaker argues that making code "easier to test" often leads to more complex and less clear code, as seen in dependency injection examples.
• 30:28 A core criticism: "the gospel of test-driven design is that anything that's easier to test is better. That's it. That's the measure of quality." "It's not better. We're losing sight of what we're actually trying to do. Tests were supposed to support us. They weren't supposed to be the main thing."
• 30:53 TDD's focus on easy-to-test units can lead to "Zombie astronautic architectures" and make systems harder to reason about, even if individual units are easily testable.
• 31:52 Citing James Coplien, the speaker highlights that "Splitting up functions to support the testing process, destroys your system architecture and code comprehension along with it."
• 32:56 The speaker advocates for testing at a "coarser level of granularity" and criticizes driving design from unit tests, as it "destroys your system architecture and your code comprehension along with it."
• 34:01 A real-world example is given where unit-tested code still resulted in data loss, demonstrating that unit tests don't guarantee overall system functionality: "It doesn't say anything about whether the whole system works."
• 36:03 The "holy trinity of test metrics" (coverage, ratio, speed) are dismissed as irrelevant measures of code quality or system effectiveness. A high test ratio (e.g., 1:4) is seen as a sign of overly complex and "anemic" tests that "don't prove shit."
• 38:13 Test-driven design, especially from a unit perspective, is criticized for increasing "conceptual overhead" and leading to deteriorated design due to the need to construct units for testing.
• 42:58 While testing "absolutely has value," driving design through "test first? In my mind, rarely has value."
• 43:25 Regression testing is highlighted as the valuable outcome of testing: "this set of tests, it's a set of regression tests, that make me feel good about that after the fact, that I can still change my system and not break it."
• 43:56 Kent Beck's sensible quote is presented: "I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence," contrasting with the extremist view of TDD.
• 1:00:21 The speaker suggests forgetting about patterns and TDD "for awhile" to focus on writing simpler, clearer code.

Take interactive transcript notes on youtube-transcript.io