Chris Johnston

Pair programming is something I have never figured out how to do. After almost two years at ThoughtWorks, this is still one skill I cannot do. I either end up watching someone else code or debating two different solutions trying to convince the other person that my way is right. I realize that both of these make me a horrible developer.

So, I would like some help. Hi, my name is Chris and I can’t pair.

There, I’ve said it. I have taken the first step and realized that I have a problem. Now if I could only figure out what the other 11 steps are to becoming a great pairer.

Here’s the thing, I keep hearing these stories about pairs who sit in front of a computer all day long, so much in the zone that they are able to right code telepathically. They never talk. They never argue. They never discuss and beautiful, simple code drips from the finger tips into the computer. Every line is surrounded by tests and their api’s will be studied from now to the end of time.

And then there’s me and my pair. I go to touch the keyboard and my pairs fingers are twitching above their keyboard like their life depends on entering one more line of code. I haven’t even written anything and they are correcting me.

So, I ask a simple question, “how do you pair”? How is it possible to work with someone so closely all day without stepping on each other’s toes and fighting about what it is that you are implementing?

I think my problem is that I am not an experienced developer (I’ve only been doing this for a few years compared to most of my pairs who have upwards of ten years under their belts) and I want to contribute something. I don’t really want to sit their and watch someone else type. However, the people I am pairing with don’t know how to pair either. They are used to sitting in front of a computer alone and banging out code.

And due to my inexperience and lack of pairing know how, I have no idea what to do?

I was in a meeting a few weeks ago where we were discussing the role of an Interation Manager (IM) and whether we needed one. Right now, the role is split between the tech lead and the BA. One of the BAs on the team stated that what we had right now was working and she didn’t understand why we were having the meeting.

This really rubbed me the wrong way. Agile is not about what works today, it is about making things better tomorrow. It is about identifying that little, or big, thing today that we can do just a little better tomorrow and implementing the change. If it works, we then find the next thing to improve and if it doesn’t work, then we try and figure out why and implemented the idea differently.

When it comes to the processes and practices we use everyday, “but it works fine now”, is simply unacceptable. It means that we have stopped moving forwards and have stagnated as a team. Regardless of how good things may seem, we always need to be asking how we can make thing better tomorrow.

My current project, on the surface, is great. We do Agile. We pair, we practice TDD, we have stories that the business prioritize for us, we have a nice card wall where we can see our cards move from the story backlog to completed. We have continuous integration with unit tests, integration tests, acceptance tests and selenium tests. And we care when the build breaks. We also have weekly retrospectives even though our iterations last two weeks.

I should have nothing to complain about, and yet, I do. However, I would like some feedback on my complaints. I think the team could be doing things better and would like some other opinions on a gripe that I have.

We have a practice of kicking off stories before a pair can begin work. This involves getting the BA, the producer (the business representative), the tech lead, the tester, and the rest of the team together to discuss a single story that a pair is about to work on. The reason that I have been given for this is that stories change too quickly and frequently and, therefore, cannot be reviewed any earlier then just before the pair begins work.

People are busy though, especially the business representative, and thge pair ends up sitting around waiting until everyone is available. A few of us have put forth the idea of doing a kickoff of all the stories committed to for an iteration during the iteration planning meeting. Then simply letting the pair work on the story when they get to it. If there are changes, it is the devs responsibility to read the story and discuss those changes with the BA and business. The conversation shouldn’t end just because everyone has done a kickoff.

Management, however, squashed this suggestion pretty quickly for the reason stated above. My take is that they don’t trust the devs to properly read and implemented the story. Which brings us to walk through.

Walk throughs happen after a story is dev complete and once again involves the BA, the producer, the tech lead, the tester, and the pair. Everyone goes through the story, dissecting it to ensure that it has been implemented correct. The pair cannot work on anything else until the walk through has been done. In the end, this means that the devs have to wait for everyone to be available.

The interesting thing is that even with all this scrutiny, I am not convinced that it results in any less bugs or better code. As far as I can tell, it simply wastes everyone’s time. The amazing thing is that the team continually votes to keep kickoffs and walk throughs as part of the process and adds things to make then either longer or harder to perform.

I can see value in each of these practices. Once you have completed a story, it is nice to have another pair of eyes take a look and double check that you haven’t missed anything. And before you start, it is important to have that conversation with the BA and business in order to clarify exactly what it is that they want. Both of these are vital parts of software development.

I think the part that bugs me is the lack of trust that is implied by the way the two practices are carried out. I feel that as a dev I am assumed guilty until proven otherwise. Until I can repeat back to the BA and producer what is written in the story, I am deemed not worthy to begin work on it. Likewise, until the business, BA, and tech lead have all signed off on a story, it is deemed incomplete simply because it was implemented by a developer. Or I could be reading to much into things.

Other devs have also commented on the lack of trust they feel due to these two practices, so I don’t think it is just me. But how do you go about changing this kind of culture? And is it even worth changing? It gets frustrating when these issues come up in retro and either management simply says no or the rest of the team votes to make them even more complicated and time consuming. I am not sure how to change an entire teams mind, especially when it seems to most people that it is working fine.