I started speaking about pair programming because I didn't like it and I needed to understand this practice better.
Sometimes I still don't.
But, I admit this:
Pairing is a great practice.
Great, but surprisingly difficult.
The ideal pairing situation requires both people to be expert developers. They need to be open to the other person's idea. And in this case (expert developers with good, strong opinions), its likely to bring pain.
If the pair is not parallel in skill (which is often the case), the stronger person must slow down and take on a mentoring role. Being a mentor when you want to be as productive as possible is frustrating. Many developers are poor teachers, but communication and discussing ideas is key to creating a great solution.
Every person you work with is different and you create a unique pair. You will go at different speeds, create different designs, even make different jokes.
Pairing is a good mechanism for teaching, but the real strength is in design and code. I have seen no other practice keep every team member familiar with every project, design and decision.
The whiteboard is rarely used because the pairing session isn't about code, its about creating. The design decisions are made when the pair needs to make them. Any previous design or decision may not be the best solution when (and if) its needed.
If discussion can be avoided, don't do it. The best way to be productive is to keep coding and evolving. Focus on small steps to deliver functionality quickly and ensures CI success.
With pairing every moment is a code review. If the team switches pairs and owns the code, everyone is familiar with everything. No reviews, no whiteboards, no documentation.
Imagine the possibilities.
Subscribe to:
Post Comments (Atom)
13 comments:
What do you think of using pair programming as mentoring?
Darius,
What kind of mentoring? Pair programming is a great way to share knowledge. People in this environment can learn new technologies and practices quickly.
Instinct makes us think pair programming is a practice for brain dumping or project rev up. However, I think of it as a method to avoid both.
-Wendy
I'm going to have to call a foul on no documentation. While the idea that everyone participates so everyone is familiar with the code makes sense, I've found that code familiarity is really only as good as the last time I touched it.
Without at least some documentation (for example, writing down assumptions) details can be forgotten pretty easily even when working in pairs.
Michael,
A foul? Maybe we should discuss documentation? Where do you write your assumptions? I write mine in tests.
-Wendy
>>I write mine in tests.
Touché
>>Where do you write your assumptions?
Unit tests. But even well written code can be hard to grasp sometimes. I've found that a little English prose goes a long way to ensuring I can follow in my own footsteps months after even my most clever moments. Unit Tests, while important, are just one piece of the puzzle.
I think we both agree that use cases, sequence diagrams, and so on are more work than they are worth but self documenting code isn't exactly free either.
About half my team thinks pair-programming would be something worth trying and the other half thinks its silly. I'm trying to keep an open mind about it because intuitively I can understand the benefits. My question to you (or anyone really) is how do you quantify this benefit -- either in cost or resulting quality (i.e. improvements in $/function point or mean time to failure?)
JoAnnP38 -- I think its hard to quantify any process. No two sprints, bugs or stories are the same so comparing them is not always valid.
Using pair programming for a few sprints and then retrospecting about how it has changed the environment, what problems it has solved and what it has caused is a great way to know if its working.
Try to think of goals you want to use pair programming for before you begin and then see if it has helped.
With respect to costs and benefits, you might also take a quick read at a scraped-together article on my site from a while ago (http://langrsoft.com/articles/pairing.shtml). As Ms Friedlander suggests, you really can't quantify this stuff. There are so many nuances that come into play as a result of pairing.
Even still, I only look to continue pairing because I enjoy it. If it sucked, I wouldn't bother.
Wendy--how often are you switching pairs?
Jeff L.
Jeff,
At Oxygen we found two matches per day worked best -- one in the morning and one after lunch. I've heard of teams that do more and less and its really a matter of how everyone works together and what keeps you working best :)
-Wendy
wunda:
two pair-programming sessions per day would be too much for me, because to really get-in-the mood of programming it takes a while.
one would suffice.
two sessions would just be unproductive for me.
Thats my personal preferences.
It's an old thread, but better late than never, I guess.
I've been practicing XP for about 5 years now. Actually this is my first full time job out of the university, therefore I really don't know how to work any other way. I had no trouble adopting pair programming, since I've practiced this at my studies with my school mates simply because we were lazy and liked to socialize. At the time I even didn't know what XP or pair programming was. I guess it comes natural to some.
About pair switching; In my opinion pair switching is a positive practice, since it accelerates knowledge and skill spread. But to efficiently consume your pair's knowledge, you just need to run a few miles with him. It just takes some time to get used to the person. Imagine putting on a fresh pair of running shoes two times a day and be expected to have the best run yet. Imagine the blisters. One pair should stick together until at least one complete story goes through. This is to build up a joint sense of achievement and trust.
This has got to be the stupidest idea in programming I have ever heard. Coding takes intense focus - one distraction and you've lost focus and will make a mistake. Constant distractions will lead to junk software. Who came up with this stupid idea? Why do people today feel compelled to come up with new methodologies just or the sake of it. If you want to be trained, go into a classroom. If you want to code, sit at a computer. No wonder the computer industry is such a mess.
Found this post while googling around, and felt compelled to answer James's last comment. :)
In terms of focus and interruptions, I'd say pair programming actually helps with this:
- Internal Interruptions: You don't tend to check your facebook when someone else is looking over your shoulder, intently focused on what you're both doing.
- External Interruptions: Unless it's important, people are less prone to interrupt two people deep in conversation.
My own experience of pair programming is that it's exhausting! Mostly because you get so much done.
Thinking of trialling it in my current team as we don't really do many structured code reviews.
Post a Comment