1. Shared Understanding
1.1. Coding Standards
1.1.1. Everyone codes to the same standards.
1.1.2. Ideally, you shouldn't be able to tell by looking at it who on the team has touched a specific piece of code.
1.2. Collective Code Ownership
1.2.1. No single person "owns" a module.
1.2.2. Any developer is expect to be able to work on any part of the codebase at any time.
1.3. Simple Design
1.3.1. Always use the simplest possible design that gets the job done.
1.3.2. The requirements will change tomorrow, so only do what's needed to meet today's requirements.
1.4. System Metaphor
1.4.1. Each project has an organizing metaphor, which provides an easy to remember naming convention.
1.4.2. BCBS Architecture is a "City"
2. Programmer Welfare
2.1. Sustainable Pace
2.1.1. 40 hour work week
2.1.2. Programmers go home on time.
2.1.3. In crunch mode, up to one week of overtime is allowed.
2.1.4. But multiple consecutive weeks of overtime are treated as a sign that something is very wrong with the process.
3. Summary
3.1. Software is too damned hard to spend time on things that don't matter. So, starting over from scratch, what are we absolutely certain matters?
3.2. Coding
3.2.1. At the end of the day, if the program doesn't run and make money for the client, you haven't done anything.
3.3. Testing
3.3.1. You have to know when you're done. The tests tell you this. If you're smart, you'll write them first so you'll know the instant you're done. Otherwise, you're stuck thinking you maybe might be done, but knowing you're probably not, but you're not sure how close you are.
3.4. Listening
3.4.1. You have to learn what the problem is in the first place, then you have to learn what numbers to put in the tests. You probably won't know this yourself, so you have to get good at listening to clients - users, managers, and business people.
3.5. Design
3.5.1. You have to take what your program tells you about how it wants to be structured and feed it back into the program. Otherwise, you'll sink under the weight of your own guesses.
4. Fine Scale Feedback
4.1. Pair Programming
4.1.1. All production code will be programmed by a pair until completion
4.1.2. Two team members at one computer
4.1.3. Essentially, all code is reviewed as it is written.
4.2. Planning Game
4.2.1. User Stories written with Customers
4.2.2. Value
4.2.3. Cost
4.3. Test Driven Development
4.3.1. Write a failing test
4.3.2. Make it pass
4.3.3. Refactor
4.3.4. Repeat
4.4. Whole Team
4.4.1. The customer should be on hand at all times and available for questions
4.4.2. The customer should be part of the team
5. Continuous Process
5.1. Continuous Integration
5.1.1. All changes are integrated into the codebase at least daily.
5.1.2. The tests have to run 100% both before and after integration.
5.2. Refactoring
5.2.1. Refactor out any duplicate code generated in a coding session.
5.2.2. You can do this with confidence that you didn't break anything because you have the tests.
5.3. Small Releases
5.3.1. Start with the smallest useful feature set.
5.3.2. Release early and often, adding a few features each time.
5.4. Customer Testing
5.4.1. Acceptance tests typically test the entire system, or some large chunk of it.
5.4.2. Written by the customer
6. Definition
6.1. Software-development discipline that organizes people to produce higher-quality software more productively.
6.2. "Extreme" means these practices get "turned up" to a much higher "volume" than on traditional projects.
6.2.1. Kent Beck