Extreme Programming?

I took some time tonight to read through the Extreme Programming links from the class blog. It had some interesting ideas, but quite frankly sounded like standard engineering practices wrapped in some computer jargon. Maybe I missed the point or maybe I'm getting to old to be taught new tricks. That being said, I did glean a few ideas from the process; spike programs and the idea of writing test code before the real code. I guess I have used the idea of spike programs since my early days in programming, but never really gave them much thought, and certainly never a name. I remember writing my first for-loop as a stand alone program just so I could see how it worked before I integrated into my program. For our class proposal I did a simple spike program on my computer to assure myself that a custom web application was possible and not out of the scope of the class. The idea of writing a unit test program first is novel. I'm not sure I buy it yet, but it might be interesting to try sometime.I do agree with the concept that the general requirements for test programs should be an up front development process. When you define a requirement, I think it is a real good idea to at least rough out the test plan that will validate the requirement. If no test plan can be developed with a go/no go result, then the requirement was probably not a real requirement (or at least it might belong in the non-functional category). I did like the idea of making the test process an automated function. Most of my life I have manually tested my software through a test harness, sometime repeating the same manual test hundreds of times before completing a section of programming. An automated test program might have save me hundreds of hours of tedious work. I could see some application for this in my proposed class project by providing a simulation and test results of each of the project sections without the need to integrate for each test. If my project is selected I will talk to the team about this option.