This is a remote pair programming codecast with Ferdinando Santacroce on the topic of Elastic Pair Programming.
When you are in a team when people know each other well and they are at the same level, having the role of driver and navigator might not be the best option because the navigator gets bored about the role. In this situation I find both the developers to share keyboard and mice so both can edit the code at anytime, to figure the solution of the problem. So we both can change the code at anytime.
We are using a simple problem: the supermarket kata. We are buying some items, and at the end the system will compute the total amount of the expenses. There is some software already, but now the Product Owner wants us to support other products and also to have some offers for some products. Also we can have combo offers.
Check the video and please come with your ideas and comments
- I generally appreciate this elastic way of doing pair programming because I find it more engaging.
- Things are done in a faster way when using elastic pair programming. One of the pairs might find for solutions while the other is continuing working.
- I learned something new about coverage.
- Switched from navigator to driver in an easy way.
- I always have a little notebook and I like to fix my ideas on a piece of paper, because any time I try to do something I regularly forget what to do for the next step.
- I need to do too much things at once, so my pair needs to make me go slower. When I use elastic pair programming, my pair is always making me go slower.
- There is a good rule with elastic pair programming: when someone watches you, you need to really go slower with your pair.
- When having the same level of seniority of skills doing traditional pairing is boring or not that effective. By traditional pairing I mean having driver and navigator, and only the driver is allowed to write the code while the navigator is focused on the longer decisions.
- The rule with elastic pair programming is to steel the keyboard when you know how to go on with the solution and stop wasting time. This is not a good thing in certain situations, like when trying to learn about the domain or when pairing with people at different levels of seniority. Traditional pairing will help you learn more about the domain, and about the technologies you are focusing on.
- Elastic pair programming is more practical, more effective and funnier.
- You don’t lose the time when using elastic pair programming. You always have progress, you never slow down.
- When using elastic pair programming there is a machine for writing code and a machine to do research and spare tasks. Obviously you need to close slack, facebook and the other machine shouldn’t be a distraction.
- Pairing when your pair is just playing on the phone or not mentally present is not really pairing. This is why you need rules like no phones, no distractions, and you need to be part of pairing even if you are not writing code.
- It is more difficult to do elastic pair programming remote, especially it is difficult to enforce the rules of no distractions from above.
- Once the team understands these rules, and uses them you don’t need to enforce them anymore.
- When using elastic pair programming the rule is to have two keyboards and two mice. There is not reason not being productive and not collaborating.
- Remote pairing is not impossible, but it is difficult to have the same engagement if you don’t have the right tools for the job.
- Screen Hero was very good for remote pairing, but it was acquired by Slack and now you need to pay for it and it might be a good option.
- For remote pair programming you need to have a good internet connection.
- The session was fun, the kata and the whole pairing experience. The kata is good to test your skills for testing orientation.
- I use this kata quite often to test the skills of the teams I want to grow about OOP. You can test a team in a couple of hours if the teams know anything about OOP.
Many thanks to Ferdinando for taking the time to record this codecast with me.
Check the previous episodes of #RemotePairProgramming:
- Ep 001: Traditional Style Pairing
- Ep 002: Strong Style Pairing
- Ep 003: Strong Style Pairing with Michel Daviot
- Ep 004: Adi & Michel Daviot – Michel as Navigator
- Ep 005: Adi & Julian – Evolutionary Design with Selection Pressure (part 1)
- Ep 006: Adi & Julian – Evolutionary Design with Selection Pressure (part 2)
- Ep 007: Adi & Tom – Tackling Legacy Code (part 1)
- Ep 008: Adi & Tom – Improving Legacy Code (part 2)