Practice: Pair Programming

[James Shore]

I’ve released two new practices, but I’m putting them in separate threads to help keep the feedback organized. First up is Pair Programming:

https://www.jamesshore.com/v2/books/aoad2/pair_programming

If you have recent recommendations for further reading about this subject, I’d love to hear it. Mine are pretty dated.

Cheers,

James

--

James Shore - The Art of Agile

voice: +1 503-267-5490
blog: jamesshore.com

[Thomas J Owens]

I'm surprised that there's no mention of introversion and extraversion in this practice. Some people - introverts - are "drained" after extensive interactions with people. There are also developers with social anxieties. For some, pair programming can be a tiring experience. There's a lot of value in pairing, but not everyone is suited to constant pairing and the team should consider the individuals before deciding on how much pairing to do and when to do it.

The section on mismatched skill levels could possibly be reworked. It seems like the implication is that a senior developer knows more than the junior developer and the best way to handle that is to have the junior developer learn something first. That isn't always the case. One example is a junior developer who learned about Java and web applications in school pairing with a senior developer who has spent a year doing embedded C development when working on a Java-based web application. The senior may have good ideas about designing software and can use it as a learning opportunity. I'd think that this section should be less about senior and junior developers and more about creating opportunities for everyone to learn.

I'm also curious about the "one keyboard" idea. The driver/navigator pairing is one option, but I've successfully paired with people using their own keyboards. One person was responsible for tests while another worked on production code. The people could trade-off who wrote the tests and who wrote the production code. This is even easier with tools like Live Share in Visual Studio Code now. I'm not sure this kind of pairing was feasible when pairing was developed, but I think finding ways to take advantage of two people, two computers collaborating on designs, production code, tests, and documentation will be a new normal, especially with teams working remotely.

--
This mailing list is for the open review of "The Art of Agile Development, Second Edition," by James Shore and Shane Warden. Visit the book home page at https://www.jamesshore.com/v2/books/aoad2.
---
You received this message because you are subscribed to the Google Groups "Art of Agile Development 2e" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aoad2+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/aoad2/7FBE8D0B-6102-4168-8C54-BA4F9E9B1F16%40jamesshore.com.

[James Shore]

Thanks, Thomas. I thought I had material on introversion in there, but it must have gotten cut. I’ll look at putting it back in.

The intention with the skill level section was that pairing is a peer collaboration, and that each person should bring their own knowledge to the table. I’ll look at revising it.

Regarding the “one keyboard” paragraph, I don’t understand what you’re getting at. Can you clarify? It sounds like you’re talking about two people collaborating on the same code using a shared code editor, but not necessarily seeing the same code at the same time.

If that’s so, it sounds interesting, but I wouldn’t call that pair programming.

Cheers,

James

[Thomas J Owens]

Regarding the “one keyboard” paragraph, I don’t understand what you’re getting at. Can you clarify? It sounds like you’re talking about two people collaborating on the same code using a shared code editor, but not necessarily seeing the same code at the same time. 

This is tool-specific, so I'm not sure how widespread this kind of functionality is.

A team has been experimenting with using Visual Studio Code and its Live Share extensions, coming away from just using screen sharing in Microsoft Teams or Slack. One of the functions of Live Share is that it shares the workspace, so people can open multiple files side-by-side in their window and see all edits made to all open files. Something that the team has been trying is having the navigator also write some tests. Both people could have both files (the main source file and the test code file) open in a side-by-side view and see what is being written in both. They can also share terminals (either for viewing or for use) and local development servers to run tests, run other scripts, or manually execute a server for the application under development.

The biggest difference between this and what I would call "traditional pair programming" is that both people can be actively doing something and see, in real-time, what is happening. You can even extend this to a mob.

I'm not sure that I would recommend this approach to people doing different units of work. I'd think that would get confusing pretty quickly. But it does allow for some rapid switching and some concurrency in editing different files, that one keyboard approaches don't really offer. At some point, I'd be interested to try this Live Share approach while colocated in a room with a whiteboard, but that's still a ways off for me.

[James Shore]

Got it, thank you.

[Bas Vodde]

Hi,

Good chapter, I liked it.

Specific feedback:

- Perhaps mention that the driver/navigator role aren’t that strict… as a driver you still think :P

- I’ve found it a good practice for a driver to say what he is doing while doing that as it keeps the navigator up-to-date on the driver’s thinking. Should you mention that?

- "Collective code ownership is socially difficult. Some organizations have trouble letting go of individual rewards and accountability.:. And the switch-back when both are interrupted is easier as you remind each other where you were.

- "Plug in two keyboards and mice so each person can have a set.”. I’ve worked with 2 keyboard/mice and with 2 monitors. My personal preference is still just one keyboard/mouse and one monitor… 

- "Give them room to figure out things on their own.”. Ask them what kind of feedback they want while they work. Some people want the “hey a semicolon” feedback and some do not.

- I’m missing the suggestion to stop and grab a whiteboard for a discussion for 10-15 minutes, and then continue… 

- "let your partner set the pace”. Agree… though there are also times when you set the pace. This is especially when your pair gets frustrated that a certain way of working seems slow (e.g. TDD) but they don’t realize it is slow because they are not used to it. Switching pace for a while to show that you can also do it fast is IMHO someimtes a good idea.

- "Mismatched skill levels”. I would merge this section in the teaching section.

- "vi vs. emacs editor war,:. That war is over, vim has won.

Thanks,

Bas

[James Shore]

Thanks, Bas.

I’ve added this paragraph to the “how to pair” section, after the “when you sit down to pair” paragraph:

Take a moment to check in with each other about each other’s preferences, too. When driving, do you want your navigtor to give you time to think things through on your own? Or would you rather that they keep on top of things so you never have to stop and think? When navigating, do you want your driver to verbalize what they’re thinking, so you understand where they’re going? Or do you want to be able to concentrate on what’s next?

Regarding the “mismatched skill levels” section, I agree. I’ve merged it.

I’ve also added this to the end of the “Effective Navigating” section:

Although the navigator generally has more time to think than the driver, that doesn’t mean the driver is a mindless automaton. They’ll have design ideas too. Encourage your driver share their thoughts, and when they have a design idea for later, offer to make a note. Also, if you get to a tricky design question, it’s okay to stop coding, grab a whiteboard, and spend some time working through ideas together.

Cheers,

James

[Avi Kessner]

I would suggest also adding that sometimes a pair/mob prefers things to be much more informal, not having the inclination/mental capacity to care or think about the "role" of those working together.

brought to you by the letters A, V, and I
and the number 47

To view this discussion on the web visit https://groups.google.com/d/msgid/aoad2/4EAE5429-F436-4F03-84A4-3E03AF67A6A7%40jamesshore.com.

[James Shore]

Good point. I’ve added this to the end of the “check in with each other” paragraph:

Do you want strict separation of driver and navigator roles? Or a casual, informal approach?

Cheers,

James