1. Test Driven Development (TDD)
1.1. 4 Step Program
1.1.1. Write a failing test
1.1.1.1. non compiling code is a failing test
1.1.2. Write the least amount of code to make that test pass
1.1.2.1. LITERALLY THE LEAST
1.1.2.2. if x > 0 return "answer a" else return "answer b"
1.1.3. Refactor
1.1.3.1. don't add functionality
1.1.3.2. fix up the code and ensure all the tests still pass
1.1.3.2.1. ALL THE TESTS not just the last one
1.1.4. REPEAT
1.2. Leads to simple design
1.2.1. Another XP Practice
1.2.2. Don't over design a solution up front
1.2.3. 9 times out of 10 TDD will lead to a much simplier solution
1.2.4. You will often reach this solution waaaayyy sooner because you started the problem ASAP, not after designing it for a few hours/days
1.3. Faster coding, Faster Feedback
1.3.1. When writing tests you can run small bits of code imediately, and often
1.3.1.1. no longer building an entire project that can take minutes or hours
1.3.2. Immediate feedback on what is working and what isn't working
1.3.2.1. automated tests can tell you when you broke something that use to work
1.3.2.2. stop doing this by hand
1.4. Every major IDE can do unit testing
1.4.1. thus every major IDE supports TDD
2. Continuous Integration
2.1. Tech Talk Presentation by me
2.1.1. buildfordisable.nicholastuck.com
2.2. the origin of this practice
2.2.1. originated from XP as code integration
2.2.2. later adopted by agile and repurposed to mean entire project integration
2.3. Definition
2.3.1. The development team should always be working on the latest version of the software
2.3.2. Upload their current version to the code repository every few hours
2.3.2.1. or when a significant break presents itself
2.4. Benefits
2.4.1. Avoid merging conflicts which can waste a ton of time
2.4.2. Share and help eachother
2.4.2.1. no your task or my task
2.4.2.1.1. it's our task
2.4.2.2. we can work our task together at any point
2.4.2.3. no delays between pc's
2.4.2.4. no delays between different schedules
2.4.2.5. no delays to make everything work before sharing code
2.5. Really Needs
2.5.1. automated builds
2.5.1.1. need to know what build works and what build doesn't
2.5.2. a respect for broken builds
2.5.2.1. need to fix a build as soon as it breaks
2.5.2.2. highest priority on the team, higher than the RTS
3. Pair Programming
3.1. Tech Talk Presentation by me
3.1.1. pairprogramming.thesoftwaregardener.com
3.2. Definition
3.2.1. 1 computer
3.2.1.1. 1 desk
3.2.2. 2 team members
3.2.3. continual collaboration
3.2.3.1. develop
3.2.3.1.1. design
3.2.3.1.2. test
3.2.3.2. integrate
3.2.3.3. everything!
3.3. Driver
3.3.1. Codes
3.3.1.1. syntax
3.3.1.2. for loop etc
3.3.2. Documenting
3.3.2.1. Test cases
3.3.2.2. Design
3.4. Navigator
3.4.1. Observes the drivers work
3.4.1.1. checking for syntax and logic errors
3.4.2. Plans the next steps
3.4.2.1. next logical step to solve the current problem
3.4.2.2. designs the next solution
3.4.3. Fights off distractions
3.4.3.1. drive bys
3.4.3.2. keeps track of new problems or things to investigate
3.5. Benefits
3.5.1. Constant Review
3.5.1.1. 2 heads are better than one
3.5.1.2. Less bugs
3.5.1.2.1. bugs are the most costly part of software projects
3.5.2. Constant Training
3.5.2.1. Everyone has specialties
3.5.2.2. we all can learn from each other and learn faster togeher
4. Simple Design
4.1. Take a "simple is best" approach to software design
4.1.1. "Is there a simpler way to introduce the same functionality?"
4.2. Simple is easier and faster to implement vs complex
4.2.1. Simple is subjective and judged by the team
4.2.2. Easier to understand
4.2.2.1. Includes better naming & clean code
4.3. Refactoring should also be used to make complex code simpler
4.3.1. Constant refactoring should be done
4.3.2. it's part of the process, it's not a separate story or task