Subj : Re: extreme programming (thoughts) To : comp.programming From : Dan Mills Date : Fri Jul 22 2005 01:32 am jen wrote: > Philip, > > 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'. Ahh, NIH syndrome, most annoying! > 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. Algorithm design should be a white board activity anyway, if writing the code is pushing the limits of your ability, then you are generally NOT smart enough to be able to debug it! Now there ARE occasional insights that most good programmers have which can vastly simplify problems, or reduce memory footprint, or speed up or whatever but it has been my experience that these are the exception rather then the rule and tend to amount to vast reductions in the complexity of the result. Being required to explain these is a GOOD thing as it often triggers useful observations from the other partner. This does require that both partners have a similar skill level! > 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? Absolutely we are here to create quality code, BUT, in general quality code is NOT the same thing as clever code! Duffs device is clever, but unless there was a very pressing reason to use it, I would not say it was quality! There are problems where the genius flash of insight is extremely valuable, but for the vast majority of programming, simple straight forward code is actually more important. I would also pose a question: How do you know if your code is quality, unless you test it? > 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. I don't think **ANY** methodology has a good reputation for pulling that off! It is difficult to see that XP could be much worse then a more conventional model. In this situation I would say that the **MOST** important consideration is that the programmers have intimate task domain knowhow. They have to be able to understand what the client wants the thing to do in order to even be able to spot the gaps in the specification. A GOOD requirements capture team with skills in the field of the application AND the time to actually do the requirements capture (it always takes much longer then expected) is another major boon to the chances of pulling this off. I would also say that if you are writing an application where reliability actually **matters**, like say a vehicle brake by wire system, as opposed to one where unreliability is just **expensive**, like say a trading floor system, then unit and module testing can take up WAY more then 90% of the development time under a conventional methodology. Regards, Dan. .