I already know a fair bit about pair programming, but the session description said, “For those already working in a pairing environment, Wendy and Oksana include some novel viewpoints and interesting discussions on familiar topics.” I think that worked out okay — it’s always good to hear how other people are doing agile, and they do a few things differently than we do.
The description also said there would be “interactive and fun games”, but the room was way too big and spread-out for that to work. There also wasn’t much time for things like that once they’d answered all the questions; people were really curious about a lot of things. Questions and answers interspersed below.
The Gentle Art of Pair Programming
Usually an interactive session with games and some hands-on practice, but they got put in a lecture room instead, with not enough time for games
- Who are those chicks? (their words, not mine — I just copied the slide)
- Let’s get to know each other
- What this pair programming is all about
- Personalities and Pairing
- Daily routines
- It’s all about the team
- Respect and communication
- Wrapping it up
Who Are Those Chicks?
Oksana Udovitska and Wendy Friedlander
- Software developers
- On cutting edge of agile practices
- Wendy likes to code nonstop, do things her way, so was hesitant about pair programming initially; but changed her mind after trying it
- Oksana enjoys pairing more than regular programming, because it’s very social
A Day In Life Of Pairing
- Morning stand-up
- This is when you break into pairs and pick up tasks
- “War room hours”
- Uninterrupted coding
- Try not to schedule meetings or get distracted.
- ~2 hours in morning and ~2 hours in afternoon.
- Break for lunch, yummy!
- Pair programming is very intense — very emotionally and intellectually draining. Need breaks. Sustainable pace.
- More “War room hours”
- Go home, yippee!
Morning Stand Up
- Standing by the story board
- Talk to the board
- Worked on this story
- Finished these tasks
- This is what we have left
- They switch pairs at stand-up, and again after lunch.
- Promiscuous pairing: the person who is newest in the task stays on
- Rotate pairs — don’t always pair with someone who thinks like you. Can use a chart to keep track.
Losing code ownership. Can stand up from a task in the middle, and have someone else take over. Trust that it will be done OK.
May not have personal desks, but there is team space. So you need to like the people you work with — but you can post pictures of your wife all over the place. Little knickknacks. Space Invaders screenshots. It seems scary, but you get used to it.
Also, there are 2-3 hours a day when you’re doing other things: making calls, researching on the Internet, going to meetings.
More than two people in the room; you’re in the same room with the other pairs on the team. They called this “osmotic information”: even if you’re not focused on it, you have some awareness of what others are doing. If another pair seems stuck, you can offer to help. If you’re stuck, you can ask for help. If you need to make a decision that could affect the whole team for the next couple of weeks, you can talk to the group about it. (But try to only interrupt if you need to, because of context switching.)
Do you have to match experience levels? — Surprisingly enough, yes and no. Make sure you both understand what you’re trying to do, but even if you’re not the best person to complete the task, you still can have good ideas on how to approach it, and you learn really fast. Oksana’s experience, as a newbie in a pairing environment, was that she didn’t feel she was dragging anyone down. You immediately learn the things that you need to know.
Depending on who you’re pairing with, it’s your responsibility to customize your behavior or put on a different pairing hat. If one person feels like they’re dragging the pair down, that’s the fault of the more experienced person. (Trading the keyboard often may help with this.)
There is no driver: there’s a typer. Both people should write every line of code. If you do it right, you’re both engaged all the time.
Coding-style conflicts: very different when you’re pairing. Wendy said she writes code in a very different style when she’s pairing than when she’s alone. Oksana pointed out that you can change the code’s style; nothing will stop you except your pair (who will probably point out that you could be writing new code instead). It becomes a lot more fluid, and people tend to start writing code, not necessarily in the same style as everyone else, but in a style that everyone else can read. Anyone can try something new, and if others don’t like it, it’ll get deleted (so don’t take it personally — must be a friendly environment). It becomes really easy to agree; the things that make sense stick around, and the things that don’t make sense don’t stick around, and you don’t even remember who did it.
Don’t you get half as much done when you have two people on the same task? — No, because:
- More focus
- Blocked less often
- More knowledge — people can take vacations without everything else grinding to a halt
- Compare cost of fixing early vs. fixing after a bug gets into production.
- Start with a pilot project on something big and risky, and see if the benefit shows.
- If the team is self-managing (as it should be in an agile shop), just do the pairing. As long as management is happy with the work, try stuff to see if it makes sense. Then reflect on it to decide whether it worked.
How many developers do you need to get this started? — Probably 4-6 developers; 6 is a little large for getting everyone to agree all the time.
What if there’s an odd number of people? — Can work alone, just needs a review afterward. Also lean on continuous integration. Or if you don’t want to work alone, you can work on spikes (research into new technology, doing the quickest, dirtiest proof of concept), or maintain the build server, or review old code.
Velocity: Different pairs of people work at different speeds. So you just have to look at how many story points you average as a team, and know that it won’t be exact. Many agile teams don’t put too much time into estimation, especially long-term estimation (and “three months out” changes every two weeks as the customer changes priorities).
How do you do employee reviews? — Everyone knows everyone’s strengths. Some people are good at coding, some people make the pair happy, some people make the pair unhappy. It becomes a team thing — the team did well, so the team gets a raise. Then maybe, if one person is especially good, they get a little extra.
Becomes a very healthy environment. Don’t have people being pathologically competitive and protective of their code and knowledge.
Documentation: customer-facing documentation only, if needed. No design docs or comments (your tests are your comments). You probably will tend to have a wiki to store knowledge like port numbers, how to set up the build environment, etc.
Do it together? Do it yourself?
- People are social animals
- We can do things alone or together
- Which do you prefer?
- Learning to communicate with a pair can help you learn how to communicate with customers
What is pair programming?
- Team effort
- Everyone participates
- No heroes
- Good to put people who are inexperienced in a task on that task
- Have to be open to failing your commitment because you’re not putting the hero on the task all the time.
- Collaboration and sharing
- Knowledge transfers — not knowledge transfer!
- More interactive
- Team spirit
- Okay to ask questions and show vulnerability
- Know others agree with your code and like it
- No more code reviews
- Readability and consistency
- You can take vacation!
Why is it hard?
- Personal interaction
- Everyone is unique
- Less personal space and time
- Very intense
- Have to do the wrong thing sometimes to keep the flow going (don’t spend two hours discussing why it’s going to fail — just write it and let it fail)
My way, your way, our way?
- Compromising isn’t good. You can’t really compromise between two different patterns; they don’t mix. Choose your battles — better to do it in a poor way, but completely. Or try it, show that it can’t work, and then do the other way (and maybe you were wrong and it is good enough).
- Know when to ask the team
- Commit. Make sure everyone on the team agrees that it’s worthwhile to try, and try it for at least a week.
- Switch pairs. Helpful if you’re sitting in the same room, or at least nearby.
- Can be done remotely, as long as you know you’ve got the technology working (VPN, screen sharing, etc.) But you do lose osmotic information; you don’t know what other pairs are doing. Cameras are helpful. Skype + VNC. Pairing is probably the easiest agile practice to do from home.
- Know your results.
- Know how to reflect on what’s working and what isn’t.
- Don’t be afraid to bring up things that should change.
- Go around the room, have everyone say something we should keep doing and something we should change.
- If you’re doing agile, retrospectives are core. Otherwise you’re being dogmatic.
The most important thing
- Having fun!
- If the walls are blank and everyone’s staring at the monitors, you’re doing something wrong. Joking, talking, arguing (in moderation).
Respect and communication
- Respect your pair
- Be open to their suggestions
- If something bad happened at home and you’re in a bad mood, you have to leave it behind
- Hiring process is really tricky. You need people on your team who will interact well.
- Express yourself and listen
Knowing when to mentor
- Pairs not matched
- It’s rare that one person won’t be mentoring. If you’ve got two experts pairing, they’re probably not experts in the same thing.
- Mentoring mindset
They think nine developers is too large for one team — they suggested forming two sub-teams, each working on its own domain, and letting people move between sub-teams.