Pair Programming, TDD and Other Impractical Things
summary
Argues that write tests first (TDD) shortens feedback loops so defects cost less, ties tests to continuous integration and refactoring, and automates acceptance via Gherkin-style criteria; recommends two people one task pair programming to accelerate learning and reduce bus factor; prescribes weekly code katas as three 20 minute rounds per hour, delete code between rounds; claims these practices measurably raise outer and inner quality and make delivery more predictable.
AI-written summary · about
chapters (21)
- 0:00Intro
- 1:53coding is not as hard as collaborating
- 2:26Listen to your customer
- 7:37First create a project mission based on business goals..
- 13:05Test Driven Development
- 13:15impractical
- 15:58most of the cost in software comes from feedback delay
- 19:061. All tests run and pass 2. Remove duplication 3. Remove opacity 4. Remove complexity
- 23:03THE CODE IS TERRIBLE!! WE NEED ONE SPRINT TO REFACTOR
- 23:14There is no refactoring without tests There is no testing without refactoring
- 25:01refactoring === design
- 26:12Focus on Quality over Schedule
- 29:30But what causes poor Outer Quality?
- 32:16How do you ensure Outer Quality?
- 32:30How do you ensure Inner Quality?
- 34:262 developers sharing a screen working on the same task
- 35:15What is Pair Programming about?
- 35:35Jon Jagger's Principles of Improvement
- 39:06Pair programming is about improving faster
- 39:29Should pairs be kept together?
- 41:24Code Katas
related talks
34mPair Programming: Better Than Adderall
01h 09mThe Well-Balanced Programmer
41mPair Programming
15mWhy TDD Is Crap
52mPair Programming: Poop & Pee adventures
32mI Have Pair Programmed for 27,000 Hours: Ask Me Anything!
13mTDD for Your Soul: Virtue and Web Development
53mHow to really work together as a team