Thoughts about Extreme programming

When we were given the assigned reading last week, concerning a programming practice called agile programming, it piqued my interest in a subset of agile programming called extreme programming. While I have heard this term before from my classmates and particularly @Joe Collard, who is an avid proponent of this methodology, I never really did any research on it myself, so today I decided to devote a little bit of time to figuring out how this methodology works. The first thing that initially came to my mind about Extreme programming was this image of programmers skydiving with laptops in hand, compiling and writing code in EXTREME conditions, or perhaps a programmer ice climbing to some remote location and living with inuits in EXTREME conditions and programming their lives away. But, that is not the case, though a bit of me wishes it was. though the downside of that is that 1. it doesn't make much sense... and 2 because then there would be a show about it on the discovery channel that would be super unrealistic and absurd... both negatives. But what I found is that extreme programming is a methodology centered around 5 basic principles: communication, simplicity, feedback, respect, and courage. Under these principles, ideally, the programming cycle is supposed to be more streamlined and is supposed to be more adapt to change because everyone in the development loop is in constant communication with each other and the program is developed in such a way that features are created, tested and added to the final project, essentially at the request of the customer. this is supposed to create a development environment where everyone is working on a singular thing instead of worrying about all the features that they need to implement. This along with a few other practices are supposed to give a very dynamic client based environment that fosters productivity and agile development. The downside to this, I think, is always relying on the customer and having them be such a big part in the development process. The worry that I have with this comes from experience with customers who have a vague idea of what they want but don't are so wishy-washy that they can never make up their mind and end up changing their wants so many times that you never really have a finished product. So, what I think it boils down to is 1. knowing your client, and 2. having some concrete program requirements that don't change that way you actually have a solid goal to work towards as opposed to some "pie in the sky" that is forever unattainable.