Tom and Malcolm,
I had an experience doing a tag-team approach also. We have a legacy FP/Win/Mac system which I've tried to avoid as much as possible <bg>. But, the interface was looking a bit dated, what with 3D controls and everything popular about 8 years ago (my the time flies!). We had a graphics design firm do a new splash screen for us (with curves!!!!), we designed a desktop that resembled a web interface -- with User Favorites -- to cut thru menu complexity.
The system has its own event loop -- basically integrating menus and forms. So, our task was to integrate the new splashscreen side by side with the old (giving the user their choice). Since I'd done some event loop development, I did the analysis. I worked with one of our programmers whose been with the product a long time. We brought complementary skills to the table -- her knowledge of the application, my implementation of the event loop. It would have taken a significant amount of time for either of us to get up to speed on the other's competence. Debugging also went quickly -- we weren't afraid to shoot ideas down that appeared deadends, but did explore avenues that only one saw at first.
I kept on comparing our task to "moving the Empire State Building a mile." That change impacted every point in the application. And, it did take several rounds of testing to make sure that each nook and cranny worked properly. But, through the pair approach, we were able to ensure that the basic foundation was sound.
It is great, isn't it Tom, to celebrate a milestone. I haven't had as much just plain fun in my programming career!
Jay
>Tom,
>
>I was excited to learn of your success with pair programming! 2 years ago (before I had even heard of the term or Extreme Programming) I worked on a small fixed price project in a team programming mode and we produced some amazing turnovers. In fact our prototype for the application became the application itself.
>
>Unfortunately, I've found it 100% impossible to have any of our clients contract my firm in this mode. Instead we are tortured with micromanagement policies that only hinder our efficiency.
>
>With the right partner, pair programming can be an awesome experience. I'm looking forward to my next opportunity.
>
>BTW, I enjoyed your joke about pair 'programming' in the construction industry. How true!
>
>Regards,
>Malcolm
>
>
>
>
>
>
>>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)?
