KentBeck introduced the XP principles in his ExtremeProgrammingExplainedEmbraceChange to help measure whether or not an adaptation to an ExtremeProgrammingPractice is supporting the four ExtremeProgrammingValues. 
* http://martinfowler.com/bliki/PrinciplesOfXP.html 

'''The rest below is kept for historical purposes'''
--------------
The hypothetical ProcessPrinciple''''''s that underlie XP's practices. With knowledge of the XP principles, we could scale XP to problems for which it wasn't designed.

Possibilities:
* EliminateDesignDebt
* BuyDontBuild
----

An interesting idea. But maybe there are two sets of principles involved here.
* The principles that were used to develop XP 
* The principles that underlie XP's practices (as stated above)

My votes for set 1 (i.e. methodology development principles):
* DoWhatYouSaySayWhatYouDo - Say what you ''really'' do, then improve it.
* TurnAllTheKnobsToTen - If a little is good, a lot is better (See TurnAllTheKnobsToSeven)
* ExtremeValues

My votes for set 2 (i.e. software development principles):
* DoWhatYouSaySayWhatYouDo 
* Fixed time increments
* Code always works 100%
** Most important things first
** Keep the code clean

-----

There is only one core principle underlying Extreme Programming that I can see:
* The form and functionality of the program being developed should grow at the same rate as the programmer's and customer's understanding of the application.

The above principle is not expressed as clearly I would like it, but it will do for now.
----
CategoryExtremeProgramming