As an Agile Coach, Miško is responsible for teaching his co-workers to maintain the highest level of automated testing culture, allowing frequent releases of applications with high quality. He is very involved in Open Source community and an author of several open source projects. Recently his interest in Test Driven Developement turned into http://TestabilityExplorer.org with which he hopes will change the testing culture of the open source community. Misko is a DZone MVB and is not an employee of DZone and has posted 38 posts at DZone. You can read more from them at their website. View Full User Profile

What Pair-Programing is Not

06.15.2009
| 5081 views |
  • submit to reddit

People often ask how can I justify two people when one will do. Will this not, just double my cost? To answer this question I think it is important to discuss what pair-programing is not.

How much of your time do you spend writing code? If you answer 100% than you are lying! Between checking your emails, going to meetings, talking to people, mentoring others, finding bugs and thinking about fixing them, coding is something we do surprisingly little of. I only do coding about 10% of time, but i am probably at an extrema, so lets say you code 25% of time. Even when you are coding, you spend a lot of time testing what you have just coded, and realizing what you have just done does not work. Your end product may be 100 lines of code, but it may take you weeks to get there.

Out of 25% of coding how much do I pair? Not enough, but lets say 25% of the time. Overall you are only talking about little over 10% of my overall time I am pairing which you can say that I only cost 10% more (if you can apply accounting logic to coding). But what does this extra 10% of “cost” buy me?

At most places I have been at when a new developer shows up, they hand him a computer and say, “OK, get up-to speed and build this feature X.” Then most places do not expect anything out of the developer for few months while he “gets-up-to-speed.” Few months? I expect my developers to check in a feature the first week! But you can’t just demand it you have to approach it differently.

Let me tell you about Arthur, the last developer which joined us for a month, and how productive he was. Arthur showed up on Monday at 9am. I sat down with him behind his computer and said, “Let’s get you up-to-speed.” I made sure that he was driving, and I was talking and we started installing all of the software which he needed to develop code. The compilers, the database the IDE, checking out the code from the repository and running it. The key here is that Arthur was doing all of the work and I was just telling him what to do. By noon, he was up and running, thanks to a very intensive hand-holding from me. We went to lunch and talked about the application, not in general terms but in specific terms which Arthur could translate to what he did few minutes ego.

After lunch, I said let’s go and fix a bug. I picked a simple bug and for the most part again i was doing most of the talking but made sure that Arthur had the keyboard and understood what, and why he was doing things. By 3 pm we had a fix. We ran all of the tests, and submitted the code. We watched the build to make sure we did not break anything.

This is pairing, and it is exhausting! By 3 pm I was beat and went home, but Arthur stayed to play some more with the code. Turns out he fixed another bug on his own before he went home. Not bad for first day. Now I could have fixed the bugs myself in 1 hour flat both of them, but then Arthur would not learn anything. I sacrificed my productivity to make Arthur productive in a single day. If I did not it would take Arthur weeks before he would figure out how to set everything up how things worked and enough courage to fix a bug. Yet that is exactly what most companies do. Think about the confidence Arthur had on day one working with us. He was up and ready and he fixed two bugs on day one. WOW!

More importantly is what we did not do. We did not get distracted by checking email. How can you, you have a single monitor, and that means that Arthur would read my email. Arthur did not waste time looking for documentation which is poor or does not exist, he was spoon fed the knowledge in the most efficient way, and he did it all by himself, i was just talking, he was typing. It is amazing how much more focused you are when you have two people working on something.

Next day, we paired some more, but this time we started to build a new feature. Again I was taking Arthur through the implementation making sure that he did all of the work. By the end of the week Arthur has implemented several features and the amount of pairing we did has dropped of significantly, but instead Arthur started pairing with other engineers which had the know how which he needed to get the features done.

At the simplest level pairing is helping people one-on-one, not through emails, let me show you behind a keyboard, instead of telling you in abstract. The amount of pairing and keeping each other on track depends on many things, but you will find that more you pair the more you will learn from each other and the better the code becomes.

But Arthur was a new engineer coming up-to speed, what about existing engineers? Well let me tell you story of Pepper the senior tech lead on a project. Pepper came to me and said, Misko, I don’t like the way we deal with X in our app, what could we do to make it better. Now here is a case where Pepper has all of the know how of his app, and I know next to nothing. So we sat behind the code and I started writing what I would imagine an ideal app would look like, knowing very little about the code. Pepper had to explain why my view was wrong or too simplistic and in the process we would learn from each other and slowly converged on an ideal design, which was neither his nor my idea wholly but a collaboration of our ideas. We started refactoring, sometimes I would drive and sometimes he would. We would take turns painting ourselves in the corner and then backing out. Many times Pepper would work without me, as the refactoring was tedious, but straight forward and two of us were not needed. All together it took us 2 weeks to finish this refactoring. Pepper did the lions share of the work, but we spent about 3 full days behind a single computer together. That is what is pairing.

If you would ask Pepper, he would tell you that pairing helped him focus. He would say that without the pair he would not have had many of the ideas which we ended up having. Most importantly there are now two people which really understand the details of the design. When I or Pepper will pair with someone else, we will share these new ideas with the new developers. As team pairs with each other ideas and knowledge multiply and flow making sure that the code-base remains consistent no matter which place you look. It is as if a single person has written it. This is a great thing which helps with maintenance.

Pairing does not mean that two people always do everything together and checking each others work, that would be boring and a waste of time. Pairing means that people bonce ideas from each other and have discussions, not in abstract, but behind a keyboard, keep each other focused and on track. Result of which is code which is better than the sum of its parts. Pairing is about sharing the knowledge with your team mates so that everyone is on the same page. We will go further if we make sure that all of us pull in the same direction, something which is rare in the industry at large.

From http://misko.hevery.com

Published at DZone with permission of Misko Hevery, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Milos Silhanek replied on Mon, 2009/06/15 - 3:41am

Yes, pairing is amusing and very efficient. I see some problem from programmer (code and strict algorithm) aspect and my analytic/designer looks from above (problem domain, user needs, consistency by other modules). We discuss each problem together and sometimes we code in pair.

I noticed too - it is good for the programmer that he does not need to read boring babbles (as laws texts) which any shadow of algorithm is not visible in. I like this translation.

Your telling was interesting. Especially about introducing a new member to problem.

Jeroen Wenting replied on Mon, 2009/06/15 - 6:27am

Pair programming is presented in all the literature as 2 people sitting together behind a single screen all day long and sharing that computer. One is typing while the other is sitting there, looking and providing a running critique of what the typist is doing. Using that paradigm (which is what every resource on XP and PP uses) the second person is 90% dead weight, 5% realtime code reviewer, 5% productivity cop preventing the person he's watching from slacking. Hardly efficient. Even were that other person to spend 30% of his time doing stuff that's not productive he'd still be cheaper than it is to pair him with someone else.

Walter Bogaardt replied on Mon, 2009/06/15 - 12:31pm

As simple as it is, pair programing requires skills of time management. In a perfect world every lead developer or manager would have the first days with a new employee to walk them through and pairing up. This goes to the point that pairing does not mean always sitting together. I think the idea here is when is the proper time to pair program, not what is not. It's obvious that pair programing is not something that works in absolute all the time. It has to be applied at appropriate times and the constraints may differ based on number of people and process factors.

Mike P(Okidoky) replied on Mon, 2009/06/15 - 12:53pm

Pair programming means knowing that someone is going to see your code, soon. It means mentally making things explanable and helps keep you from getting absorbed in a goo of abstract fuzziness. It can be frustrating if the person you're pairing with, isn't very experienced. You end up walking through your code with the other guy just nodding until lunch time.

What might fix that is that if the guy you're pairing with, gets to provide a summary for the guy that will be pairing with you next time. That forces the other guy to pay attention.

 

Jesse Gibbs replied on Mon, 2009/06/15 - 7:01pm

One of the key benefits of pair programming is that code is reviewed as it is written.  A really common mantra has become 'at least 4 eyes on every line of code'.  And everyone knows that the earlier you find bugs the cheaper it is to fix them.  Well, if another developer is catching your bugs as you write the code, it doesn't get much less expensive than that.

Unfortunately pair programming is a practice that isn't widely adopted, or is not used consistently throughout the development cycle.  At JavaOne, several developers I talked to mentioned that they have used pair programming at the start of development cycles, but then moved away from it as deadlines came closer and everyone went 'head's down' to get the release done.

At Atlassian we have tried to make our code review tool Crucible (you can check out the new 2.0 beta at http://www.atlassian.com/software/crucible) work for teams that are doing peer code review as well as teams where developers work individually and/or are distributed across different locations and time zones.  Along with a few other innovative tools like Smart Bear and ReviewClipse, Crucible let's developers get the benefits of code review without having to significantly change how they work, or sit through a bunch of boring meetings.

I'd like to here if folks have found other tools that make pair programming more effective?  Or enable them to get the benefits of pair programming without having two developers to a computer?

Igor Laera replied on Wed, 2009/06/17 - 6:34am

My only contact with Pair Programming in the past had left always some sort of "bad taste" in my mouth. What the poster referes to is some sort of "best of breed helping-version" of pair programming. My experiences run more into the worlds of "one master skill is forcefully paired with some freshman from college", where you have to watch endless configuration and boilerplate stuff, until something "pair programming worthy" happens. Usually less then 30 minutes/day. It's said that the freshman will come up to faster productivity, but you waste a pro for a full day. I could accept that, if this is was not the concept of "pair programming" for weeks to follow. Usually you started bringing books and magazines to work, because the youngster had to change something on 20 webpages and it was enough to look on it for 5minutes after each page. Nice in terms of stress, but that's not how i see my profession, which needs practise every day. Other experiences didn't differ much from that. It was always if the management sought-after for some silver bullet to make that "complicated it business" better, and it was never really an cohersive concept behind it. I can see the worth of pair programming, but I never saw it really working "in the field". Sometimes we use Eclipse-Remoting todo code reviews in teams, which works very well. I have the feeling (and the results that prove this), that other aspects of the new "agile development model" help much better to avoid drowing in bugs and keeping timelines than sitting together on some piece of code. There are alots of other techy jobs where nobody is helping you ad-hoc, so I don't see the reason why developers really *need* another person looking over their shoulders to perform better. But everybody has a different view how s/he sees his/her profession. -zen

Jeroen Wenting replied on Thu, 2009/06/18 - 12:17am

Seems like you were pushed into mentoring people under the guise of pair programmng, zen. Which is pretty much my experience (though not to the same extent, the people I worked with were proficient as programmers, just unfamiliar with the environment and need a bit of being shown the way through the codebase and company network).
At least when I did it that was the stated goal, give someone new a kickstart to productivity. I don't mind doing it, as long as it doesn't last too long.
Sharing knowledge is important, but in my experience once someone is loose on the specifics of a project that's best done on an ad-hoc basis.

Uwygefiwue Wiue... replied on Sun, 2009/06/21 - 5:29pm

With all the respect this article and most of the comments are matching the title - "what PP is not about". Please see this article for more insight what PP is: http://digg.com/d1sBRV pls check the section "typing is not a bottleneck"

surabhi singh replied on Mon, 2009/08/03 - 4:51am

<p><a href="http://www.national-ambulance.com/">ambulance medics</a> - this site is lead by two distinguished paramedics who have been in front line ambulance work for some years,
we offer medic diaries, ambulance topics and articles of high quality

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.