I read an interesting blog post by Mark Needham today that talks about some anti-patterns he found himself falling into while pairing. I have also caught myself being guilty of some of these offenses so I thought that listing some here explicitly will help keep it fresh in everyone’s mind. Of coarse what works some may not work for everyone, but here is a small list of behaviors I which I find can negatively impact pair-programming…
Moving around the code too quickly
As the driver, it is normally a bad idea to be changing windows/files/tabs/etc. too quickly while you are in control of the computer. It is easy to forget that your navigator may not know what you are thinking so you find yourself flying through the UI of your workstation at lightning speeds only to have your pair say “Ok… what just happened?” Granted, following a driver’s every keystroke is not the navigator’s concern, I do find it helps collective code ownership to have the navigator pay attention to what the driver is doing. Therefor, I believe that it is always a good idea to communicate to your navigator what you are planning to do BEFORE doing it which also give them the opportunity to offer any input they have before everything has been said and done.
Grabbing the keyboard away
This one is a little more obvious as to why it is an anti-pattern but let me elaborate anyway. My opinion is that it is NEVER a good idea to take control of the keyboard and mouse without asking first. I have seen it happen for various different reasons; lack of time, lack knowledge, lack of patience, lack of discipline, and lack of respect. Sometimes you just want to finish your task and you know you can get it done quicker or maybe you are really excited about trying to solve the problem and hand and anxiously snatch control of the computer. Sometimes the guilty may have all of the above reasons for this behavior but I don’t think it should ever be acceptable. By taking control, you are giving your pair the impression that you think they can not accomplish what needs to be done or that you can do it better. It is always a good idea to ask first before taking control and if the driver was in the middle of something, you’d better have a good reason. This also promotes better communication because you more often have to attempt to explain your ideas to your driver instead of just doing it yourself.
Vacationing as the navigator
Pair programming often come with negative connotations because some ask “Well what can/should I really do as a pair?”. The reality of it is that pair-programming involves two distinct roles each with their own very engaging responsibilities. The driver is tasked with controlling the workstation to write the test cases, code, and refactor. The navigator should be involved with design decisions made while writing the code but they do not necessarily have to be reading every line of code the driver writes. Instead, they should be thinking of what test cases come next, whether or not the existing tests are passing, can we commit, and most importantly: “Are we done yet?”. This is why it is very important to not become detached from the task at hand while your driver tries to figure out where he is missing a semi-colon. Distractions like mobile devices, food, twitter, etc. can often lead the the navigator not having a plan which leaves both people in the pair asking “What next?”. This is not to say that a driver cannot become distracted as well but, in my experience, I have found it harder to fall into the trap when you are the one engaged at the keyboard and much easier when you can literally twiddle your thumbs. Just remember you are there as a supportive role to your driver and they are lost without your “map”. To help avoid this, it is a good idea to make sure you are switching roles often to keep both people engaged in the task at hand.
You can check out the original blog post which inspired this one here.
I am also interested if anyone else has any other pair-programming anti-patterns they would like others to be aware of. What do you find negatively affects a pair-programming situation? Or for that matter, any tips on how you have become more effective? Feel free to share!
My Point2 workstation recently received a monitor upgrade; the old pair had had served me faithfully for many years, but they were worn out. So I am now the proud user of a pair of shiny new widescreen monitors.
The new monitors are much nicer than the previous monitors, and they are also a much higher resolution (1920 x 1080 vs 960 x 1280). Using them is a very enjoyable experience, but at first it seemed like the widescreen aspect ratio was wasting a lot of horizontal space:
Then a few days ago, in the middle of a pairing session, I discovered IntelliJ’s split screen feature. In my opinion, the combination of a wide screen monitor and split screen is a killer feature for TDD. If you assign your test code in one pane, and your production code to another pane, you can see your test and production code at the same time:
To activate split screen choose “Split Vertically” from the Window menu, or right click on a document tab and choose “Split Vertically”.
IntelliJ works very nicely with this split screen configuration; intentions, “Go To Declaration”, and refactoring shortcuts jump nicely to the appropriate screen. Being able to read test and production code at the same time without clicking a button is especially valuable when pairing, as each half of the pair can be reading a different file. One important caveat: this only works correctly if each file is only open in one pane, and IntelliJ doesn’t enforce that for you.
Some of you might wonder what the second monitor is used for, and the answer is pair programming. We pair program all the time at Point2, so I run the two monitors as mirrors. I’ve also added an extra keyboard and mouse, and the combination allows each member of the pair to see exactly what’s going without craning their necks or stretching. It’s a really nice feature for a pairing station.
By: Sean Reilly
My wife and I plan our finances each month. We look at how much we spent in the previous month and why, and we project what we will spend in the upcoming month. It’s pretty lo-fi: A 20 column ledger and a spreadsheet. The ledger is always lying out and open so we can write in it as soon as we get home.
The spreadsheet is for calculations and planning. At regular intervals we sit down together, Wendy and I armed with our favorite tools. She relays the numbers from the ledger and I enter them into the spreadsheet. Wendy is focused on reading and relaying the numbers while I am focused on data entry. Once the numbers are in we quickly double-check just to be sure. The process takes less than 5 minutes for 40 – 60 entries.
This time Wendy did the data entry on her own. I asked how last month looked and she said “We spent a lot on groceries”. I happen to like eating so it’s not a big deal that we overspent, but it’s still nice to know why it happened. There is always a reasonable explanation. Meat is a major portion of the bill, and maybe we bought too many bags of frozen peas. Or maybe there is a mistake in the data.
Had we paired during the data entry we would have been assured that the entry was in fact correct and we could begin a meaningful analysis of our overspend. I am now forced to look back through the data in the ledger and ensure that it has been entered correctly. This will take more time because I will be switching tasks many times:
- Find the entry in the ledger
- Remember the value of the entry
- Move eyes from paper to spreadsheet
- Scan to find the corresponding entry in the spreadsheet
- Recall the value of the entry
- Verify the values
Compare these steps with those that I would do when pairing:
- Translate what Wendy said
- Verify that the value she relayed is correct in the spreadsheet
Yep, only 2 steps. I don’t have to keep switching focus from paper to monitor, nor must I remember any values. I just verify that the value she gave me is the value in the spreadsheet.
When I sat down to verify our numbers, the realization that pairing is much more effective (and arguably more efficient) hit me like a ton of spaghetti code. When you are working on complex tasks you are forced to make switches between contexts – the problem and the solution details. In my example the problem is incorrectly entered data, and the details are moving my eyes from paper to screen, then remembering and verifying values. When writing code the problem is the bug/story you are playing, and the details are language syntax, editor shortcuts, etc.
Now to the point. Imagine that you could offload one of the contexts and fully focus on the other. Wendy can focus on the problem (relaying the numbers) and I can focus on the details (data entry). When writing code the navigator is focused on the problem (satisfying acceptance criteria and design) while the driver is focused on technical details (syntax, shortcuts, stubs, tests…). It stands to reason that pairing prevents mistakes due to context switching, thus solving problems more thoroughly and with fewer mistakes.
P.S. – I asked Wendy to pair with me on the verification. Next time I won’t be so lazy and I’ll help her do the data entry in the first place 🙂
By: Ryan Shuya