Malcolm;

One aspect of XP programming I enjoy is pair programming. We used this approach on a major project about six years ago. Our quality and productivity went up measurably. We were able to do things that were required but no one had done before. We pushed each other and laughed a lot.

There were lots of "high fives" after creating something new. I think management thought we were nuts but we produced and our code was good! In fact we released our code after we tested it and our SQA department passed it after they tested it. No broken code! The two of us thought about different things to test and I think this also helped. No two people think alike.

Pair programming reminds me of a story my brother-in-law (a General Contractor) told me about the construction industry. Two men that work together well will do the work of four individuals. Two men that do not work well together will start a war! :)

Tom


>Hi Jay,
>
>Here are 2 books I enjoyed. I'm not sure if they're the best XP (Extreme Programming) books out there, but they were significant enough for me to begin re-thinking my design, development, and testing methodologies from scratch.
>
>Extreme Programming Explained: Embrace Change (The XP Series) -- Kent Beck
>
>Extreme Programming Installed (The XP Series) -- Ron Jeffries, et al.
>
>Both of these books are in paperback format and they're very easy to read. Not a lot of scientific mumbo jumbo, theory or statistics - just some basic 'common sense type' wisdom with some (IMHO) reasonable rationalizations.
>
>If you decide to explore further, I would enjoy discussing the topics in more detail.
>
>Also, if you're really curious (or have time to burn on a Friday!), visit the www.extremeprogramming.org web site and surf around. Lots of 'nuggets' - some good and some contraverisal enough to 'think on' for a bit.
>
>Regards,
>Malcolm
>
>
>>Malcolm --
>>
>>How have you found xTreme programming useful for you? Any particular titles?
>>
>>One publisher has a whole series of books out on the topic. For the curious bystander, I'd think that one book should suffice to cover the basic approach <g>.
>>
>> Jay
>>
>>
>>>Fred,
>>>
>>>For some great thoughts on testing and integrating testing into your programming efforts 'holistically' vs. formalizing testing as a seperate and independent phase of development, read up on Extreme Programming.
>>>
>>>For a good start there's www.extremeprogramming.org.
>>>
>>>And/or go to Amazon and search on the topic 'Extreme Programming' and read the reviews.
>>>
>>>Although not a book about testing per se, the work 'The Mythical Man Month' is a classic for analyzing ratios and estimating time lines. Worth reading in and of itself.
>>>
>>>The above advice aside, my experience on working on large software projects at big corporations is the following:
>>>
>>>- Testing budgeted at 10-15% of project effort
>>>- Time required for actual testing - 25-40% of project effort
>>>
>>>Good topic - I'm interested in following this thread.
>>>
>>>Regards,
>>>Malcolm
>>>
>>>
>>>>>Is a general estimate of the ratio of programming time to testing time?
>>>>
>>>>Let's try this in English.
>>>>
>>>>Are there any general rules or guide lines covering the amount of testing time in regards to development time (actual programming hours)?