Programming In Pairs Testimonials

One Person's Experience

I've been doing PairProgramming for the last week and-a-half (in T-SQL). I've done pair design and CodeReviews before, but never tried true pair programming. It is pretty hard, let me tell you.

First, the good points. We finished in just over 2 days what was scheduled to be completed in 5 days. The quality is very high, things look good, and we know how to extend the base primer stored procs to accommodate future changes in required data. I was better at T-SQL programming than my partner was, and he was much more familiar with the business logic and data model than I (since I've been working on the project about 5 days total). He would explain what he was doing as he went along and I would ask questions if I did not understand something. In the beginning, I just stared back at him as he talked. I probably looked like I had an IQ of 20 (it's at least 25, honest!). But as time goes on, I am picking up a good understanding of what we are dealing with and how it all fits together much more quickly.

On the other hand, I contributed a lot of SQL knowledge and basic error-checking before we compiled and ran the procs (which, if we ran the entire set, took 20+ minutes), so this definitely sped things up. Also many times, my partner would be thinking 2 steps ahead of his typing, and would skip something that immediately jumped out at me because I just saw him do it 5 minutes ago. Time saver again! Plus, it seemed like there was something that helped about having to explain and defend yourself to another person. It forces you to be pretty darn sure of what you are saying.

Now, the bad. Many times it was very frustrating to have to "bring the other person along" when you were on a roll. All aboard! The train is leaving the station! You don't want to have to stop the train to pick up the late passenger. Another aggravating thing is when the other person does not use keyboard shortcuts! So many times I wanted to scream "Use the keyboard shortcuts!" (I bit my tongue instead, and I think it worked out better that way.)

On the whole, I think this was a very good experiment with some very good results. As we leave the critical base of this application and commence to writing the report queries, I think we will split up. I will be able to write queries without having to bother my partner too much, and he can figure out how to fix SQL errors without asking me all the time.

Other than the prospect of having a job I like so much shipped off to India, nothing depresses me more than pair programming.

Prima Donna programmers hate it! Programmers with confidence love it!

If you truly have the ability, it shows. If you don't, it shows. There's no hiding it.

That said, put two programmers together with confidence, modest ego, and pair programming works like charm. And it can be fun.

Pair Programming went down in flames on our project and the programmers hated it. Ergo, the programmers on my team must lack confidence and are prima donnas, although I personally tend to like them and cannot really see any significant personality differences between them and any of the other programmers I have ever worked with.

I tried pair programming in late 1980s and through 1990s, before the XP was even invented, I believe. We weren't ahead of our time, it's just that the company we worked for had no money to buy computer for every programmer. From my experience, pair programming doesn't take productivity to a new level. It is normally better than one person on one computer but worse than two people on one computer each. Probably, one and a half programmer per computer would be the best, if it were an option. The other thing is that pair programming works only if personalities match each other, just as with any other job where people work as partners. It is very much like sex - you can have it with practically anybody, if it is only once or twice. The long relationship, however, takes patience, tact and a lot of social skills. And considering the nature of programmer's job, you are likely to do something S&M together, so choose wisely!

The only type of pair-programming that's possible in these days of instant coffee, bugfixes, job insecurity is with me and myself.

Well my pair-programming was a complete disaster. I was always arguing with my pair partner and very little work was done. I was less than 1/2 as productive as I was by myself. My pair partner was about 1/2 as productive too. So in total we were 1/4 as productive. Complete disaster.

I worked for a company that partly implemented XP. We had many pair programming sessions and I must say that I was in the "zone" many times, which led to the most impressive code in the shortest time. A key thing to this was keeping a open mind and having a good partner who is willing to see your point of view. I also think its a excellent way of getting a new employee up to speed on a project!. -- David Winslow, http://www.xpmentor.net

The comment of one and a half programmers per computer is not that far off the mark... try three programmers (a small team) using two computers. I feel this is a very flexible approach: one can go off alone whilst the other two can pair, swapping as needed; they can brainstorm as a threesome; an odd number is good (helps to have a casting vote); able to produce parallel coding (try out two good ways in parallel, with the third member being the go-between); increases experience for all; etc.

My and a friend of mine began to programme when we were 11 years old (in the 80's). We were doing pair-programming but we didn't know nothing about it. After 7 years of programming together we were so coordinated that we almost didn't need to speak to understand the other one. Sometimes we used pair-programming to share the memorization of too much information (maybe the long rows of 'DATA' defining a sprite in the Commodore 64). When we began to study Computer Science (in the 90's) people looked at us and say 'What are these two guys doing sitting at the same computer and saying almost nothing?'. We were pair-programming.

Nowadays my friend works for a boring-code-computer-enterprise and I'm a mathematician. Both of us miss those nice and funny hours of friend-pair-programming.

I along with a colleague of mine went through this experience unknowingly and i recently came across this concept of pair programming. It was a great experience which made it so simple for us to design a typical algorithm step by step and code it. Many of errors were avoided by this and it took us 30-40% lesser time for doing the same work. The result was a well designed algo giving efficient output.

I hired two computer science students from the local university (highly-rated for its CS department and selectivity). I made them work as a pair on a project to create a threaded TCP multiplexing server in C on Unix.

The resulting code was far beyond my expectations, and the best student project I'd ever seen. It worked flawlessly, and has been in production servicing billions of connections for over four years.

That said, I do believe personality figures highly into the success of the pair programming project...

In my first micro implementation, myself and a colleague worked in this way as there was little or no literature to support what we were trying to do. We developed hardware and software from scratch and delivered an industrial process control system in about 6 months. To a certain extent this situation was forced on us as we only had one development system (very expensive in 1978), but we could have apportioned the hardware / software development differently.

All in all, I believe it was beneficial to our understanding and to the success of the project. Neither of us working alone could have accomplished the task in the time scale.

I once managed a small development team in a very large company steeped in traditional waterfall. Knowing that a wholesale switch to XP practices would not happen easily nor quickly, I rolled out parts of XP and refactoring concepts in small chunks. Pair programming was certainly a hard sell since there was no higher level management support. When I went to the team to discuss the idea of trying pair programming, one of the developers shocked me by saying "Oh, we already do pair programming here."

His explanation requires context. Since the overall software shop was easily 1000 developers (we were a team of 8) and everyone was working on features or sub-applications of the same product (an engineering tool used by many manufacturers, including aerospace and automobiles) there were often large infrequent release "events". These release events were scheduled long in advance and every developer knew the date and time of the code cut-off. Often it happened that after the cut-off some very serious defect would be found and a last minute repair would need to be produced before the final golden master release of the software.

His point was that whenever a programmer was working on one of those last-minute serious defects, the programmer always paired with someone. The second individual would be there to real-time check the code because "it had to be right". Apparently, everyone understood that when quality was essential we pair programmed.

One of the skills of the manager is to work out when pair programming is appropriate.

For example, I recently lead a small team to build a B2B system in J2EE. The skills required were the usual mixture of domain-specific (knowledge of the data model) and technical (knowledge of the development platform). So pairing a long-term team member, who understood the model, with a recently-recruited Java enthusiast worked well. I'd be lying if I said that the system was developed quickly or to a high level of quality... but frankly, without pair programming, it wouldn't have been developed at all!

On the other hand, it's clearly a waste of manpower to have two experienced programmers working together on a routine enhancement in a well-known platform. In that situation a more sensible option would be for them to work on different enhancements, then code-review each other's work.

CategoryPairProgramming