Was it just me that read 'Meg Hitler'?
That is all
5 publicly visible posts • joined 12 Nov 2006
The argument Matt gives against pair programming doesn't mention three of the key benefits for pair programming, knowledge sharing, continuous code reviews, and discipline.
Knowledge sharing in terms of learning more about different parts of an application, this is further enhanced by promiscuous pairing where you only stay together for a story/requirement/use case I have paired with people at all levels from junior to architect. I have certainly contributed in different ways in each pairing, but we have always both contributed and I have seldom felt that it was a waste of time. If there is someone on the team who wont pair they dont belong on the team. Everyone has to play be the rules.
Code reviews in terms of ... well kind of obvious really, you are having two pairs of eyes always looking at the current code, and next time you get another pair working in that area you get two more pairs looking.
Discipline in the form of not being able to get away with writing that test after you finish, or i'll just put a small fix in here where I should really refactor this code.
This is not the same as the beneficial 'do the simplest thing that could work' (pairing helps prevent complex minds infecting code). Simple good, simplistic bad.
Eclipse is a pain the arse to use. Every time the intuitive IDE (IntelliJ IDEA) releases a new version there is a scramble by the Eclipse boys and girls to emulate the new features. The vital piece they leave out is the ease of use. Perhaps they are hamstrung by the fact that eclipse is not actually a Java IDE it is a generic workspace environment, and therefore suffers from the all things to al people problem.