Subj : Re: extreme programming (thoughts) To : comp.programming From : Phlip Date : Fri Jul 22 2005 12:09 am jen wrote: > No, I actually didn't imagine Matt could be doing more than 2-3 hrs > pair programming at a time, which is what my experience was. I was part > of some pair programming at my previous company where, unfortunately, I > saw a lot of nervousness and incorrect decisions being made because of > anxiety over 'how smart am I looking now'. One of the most surprising > errors came from a programmer I was pairing with who had > 15 yrs > experience and was excited about pairing. That's my experience at it, > and I wasn't against XP at the time; I thought perhaps this experienced > programmer could teach me something. But, it didn't happen, not in this > manner. The big problem in general is legacy code. Writing new code from scratch under TDD and by pairing is a relaxing pleasure. But who needs new code? > I personally cannot think through a difficult algorithm when I'm > sitting next to someone else. The rule is "pairs write all production code via tests". Not all software engineering is cutting production code. To invent a difficult algorithm, code solo if you like, and test-last if you like. Then trivially port your tests to the project, with a pair, and use the tests to reconstruct your code. > I need a lot of time at one stretch to > sit back and consider how the recursions need to go, or how the > function needs to be created (which is why I think some programmers > should have an office). > > Philip, how is it even possible to write difficult code while pairing? > Seriously, how can you write a mathematical algorithm with another > person sitting there, who may not know anywhere near as much as you, or > vice versa? I just don't see it as a reality. Another thing to learn (often by pairing) is how to write difficult code by writing dirt-simple tests. If you need to invent a language, the first test should compile and execute "puts 'hello world'". Trivially pass that, then write a test for the next least complex requirement. Keep going, refactoring the code as you go, until you have something complex. You cannot disparage TDD in isolation from pairing, or vice versa. Both suck alone. TDD can help you rapidly write code nobody can understand, which has many more features than you need (all bug free!!!). Pairing while using the usual code-and-fix or big-design-up-front is heinous. Pairing during algorithm discovery is sometimes irritating, in which case you should not do it. However, sometimes you pair "in flow", and when the algorithm is finished you cannot remember who had what idea, or wrote what line. Pairing can be like a vulcan mind meld. When it is not, and when you are not inventing an algorithm, it's at least supportive and tolerable. > I don't believe that any of the great authors, poets, > composers, etc. could or would work in pairs. Are we not here to make > quality code? Are we not here to create something > beautiful? Nope. We are here to find the cheapest and most sustainable way to help end-users profit from simple code, as soon as possible, so they come back for more. Quite the _opposite_ of chiseling a work of beauty from a big block of marble. > If you're just talking about hacking out some accounting program, then > you can use XP or a hole in the ground if you want; but if you're > actually talking about writing an application that is elegant in the > code as well as being extremely complex algorithmically and large in > design, then I don't see how XP can do it. Those who have tried XP, with a better-coached team than Matt's, generally report they are surprised how clear and elegant the resulting code is. This effect is very widely reported. -- Phlip http://www.c2.com/cgi/wiki?ZeekLand .