As I wrote earlier I attended my first ever Alt.Net un-conference this weekend. It was very rewarding and great to meet fellow developers under such informal circumstances. The open spaces was the most rewarding part I think.
One of the open spaces I took part in were about Pair Programming. It soon evolved to a session about how to convince developers / management and other that it’s a good idea.
Here is a short recap of some of the good thoughts that emerged from that session.
Good ideas
- Switch the keyboard often. I.e. one developer writes the test and one the implementation or use some kind of a pomodoro clock for ten mintues.
- Switch partners often – once a day for example
Argument for the benefits of Pair Programming
- It’s fun! No more agrument should really be needed than this. You need fun at work or else you should work somewhere else.
- This is a list of benefits here and then some studies that shows an increase in quality etc.
- It may be slower to the first checking but faster to production
- A higher quality to immediate quality checking by the partner
- More people is familiar around the code-base
- Higher degree of concentration and fewer interruptions, both internal and external.
- Here is a paper that states that you do loose tempo (15 % in their studies) but you gain in quality
Yeah – that pretty much sums up what we talked about. And finally, if they still are uncertain, try it for a sprint and see. And change what isn’t working.
2 comments:
I agree about the "Good Ideas" - you should change partner often. But if your team members are new to pair programming it can sometimes be a good idea to avoid frequent partner-switching in the beginning so that the pairs can let it sink in with someone they (learn to) trust.
A very good comment, Jocke. I think that caution and carefullness (?) is the way forward when pairing people.
There are some people that just like sitting alone and there is no forcing in PP.
Post a Comment