Ooochie: A Ruby Developer’s Journal

Now that we've gone over the values that drive XP (Part 1), we're ready to talk about the principles that guide XP. Beck defines principles as "a set of domain-specific guidelines for finding practices in harmony with XP's values." We need principles because they act as a bridge over the gap between values and practices. "Values don't provide concrete advice about what to do in software development." Principles help make it easier to derive practices from the values outlined in part 1. The principles that guide XP are the following:

Humanity

• People need basic safety, a sense of accomplishment and belonging to a group, the opportunity to grow, and the opportunity to understand and be understood.
• People need free time. Time away from work allows for more energy to bring back to the team.
• Private life details confuse team communication. Keep private matters private.

Economics

• Make sure what you are doing has business value and serves business needs.
• Earn money sooner and spend money later.
• Try to enhance "option value": options for future use of your product.

Mutual Benefit

• Every activity should benefit all people involved. If it costs one person, relationships will begin to break down.
• Automated tests help you write better code now and act as documentation for future programmers, therefore benefiting all parties.

Self Similarity

• Try copying a good solution into a different context.
• Write a test that fails, then make it work.

Improvement

• "Perfect" is a verb, not an adjective!
• XP is excellence in software development through improvement.
• Do the best that you can now with the intention of doing it better tomorrow.

Diversity

• Teams where everyone is alike are not effective: a variety of skills and perspectives is necessary for success.
• Diversity leads to 'conflict' (i.e. more than one solution). All ideas should be valued and respected.

Reflection

• Think about how and why you are working.
• Learn from your mistakes and the mistakes of your team members.
• Reflection comes after action.

Flow

• Deliver a steady flow of valuble software.
• Deploy small increments of value frequently.

Opportunity

• See problems as an opportunity for change!

Redundancy

• Difficult problems should be solved in several ways in order to prevent disaster. (i.e. Defects are addressed in XP by continuous integration, pair programming, customer involvement, etc. All these things are done to solve the same problem: bugs.)

Failure

• "Failure is not a waste if it imparts knowledge."
• When you don't know what to do, try something. Risk failure.

Quality

• Increases in quality lead to increases in productivity and effectiveness.
• People need to do work that they are proud of.

Baby Steps

• Momentous change all at once is dangerous.
• Take many small steps rapidly.(i.e. Test driven development, continuous integration.)

Accepted Responsibility

• Responsibility cannot be assigned, you have to accept it.
• If you are responsible for implementing story, you are also responsible for designing and testing that story.

As Beck puts it, "The principles give you a better idea of what the practice is intended to accomplish." Now that you understand the principles, you already know the goals of XP. The practices, which I will outline in part 3, are the things you can do to accomplish these goals.

Part 3 coming soon!