Nov-6-2008

Pairing for Quality

Post written by Chris Spagnuolo. Follow Chris on Twitter 56 comments

pairon.jpg OK, so if you didn’t guess it, quality software has been on mind a lot over the past two weeks. And why shouldn’t it be? It should be foremost in all of our minds (if you’re in software development). It’s what our customers expect and demand. They don’t want buggy, defect ridden software. Unfortunately, things like software quality and testing are usually seen in a budgetary/cost light instead of the customer satisfaction light. I’ve beaten this point to death already and by now you already know that in my opinion customer satisfaction is paramount. And, anything we could do to improve the quality of our products should be pursued vigorously.

We’ve discussed the CIO commitment to quality already, and we’ve looked at ways to tightly couple QA/testing into our iterations. Today, I started thinking about other places in our development cycle where we could really show great strides in improving software quality. I think I found one: Lets take a look at pair programming. The first thing most people say when I mention pair programming is “Why would we do that? We’ll have two developers doing the same work that one developer can in the same amount of time!”. OK…fallacy number one: This simply isn’t true. Studies have shown that pair programming doesn’t reduce productivity by 50% as implied by the previous statement. In fact, pair programming reduces productivity by only about 15%. WHAT!!!! Yes, I admitted that pair programming reduces productivity. But, the 15% loss in productivity is made up for by gains in reducing defects.

Two pairs of eyes on the same code as it’s being written has been shown to dramatically reduce the number of defects in the code. So much so, that if you factored in the gains recovered by NOT having to fix defects later in a development project, or worse yet, in production, the productivity of pair programming is 100% of what it would be if the two developers worked independently. That’s right, we more than make up for the 15% of productivity lost by pair programming by not having to fix defects later on in our development (or worse yet in production). Plus, cutsomers (remember them?) get the added bonus of low-defect or defect-free QUALITY software. Based on these facts, the productivity/cost argument for not doing pair programming is essentially invalid. So, the next time you hear the productivity/cost argument against pair programming, resist the urge to agree with it. Pair programming works. Try it, you’ll be amazed at the results.

Share on Facebook
Post to Google Buzz
Bookmark this on Yahoo Bookmark
Share on FriendFeed
Bookmark this on Digg
Share on reddit
Share on LinkedIn
Share on StumbleUpon
Bookmark this on Delicious

  1. Per Lundholm said,

    It is oh so tiresome. You can’t relax because if you do, the other guy jumps up and pushes you forward. As soon as you go off wandering into some interesting and esoteric, you hear “what are you doing, you don’t need that”.

    Should you try to break the architecture to get your quick fix in, there is a nagging from left: “we shouldn’t do that”.

    Besides that, the other guy gets to know all your secret tricks that make you productive and look smart.

  2. David Vandervort said,

    The times when I’ve done pair programming I found it to be excruciating. The alleged increase in productivity is dependent on both the skill levels of the programmers involved relative to each other and their comfort with each other. They have to be able to talk and even argue over minutiae without losing time or beginning to hate each other.

    Too much difference in ability or too little comfort and at least one of them will be simply spinning his wheels.

    Pair programming can work very well for the right pair. But for most of us, it is not only a waste of time but an unbearable experience. Having tried it, I now avoid it at all costs.

  3. Will Smith said,

    In my experience, pair programming has exhibited immediate benefits. An extra pair of eyes can go a long way. More defects are found early. And, the design improves when two people are looking at the code. It has to make sense to both of them. That said, there is definitely a short term hit on productivity. Finding defects early means more time now and less time later. Also, these benefits can be difficult to measure. This is why it can be so difficult to sell the concept to management.

    As we all know, it is impossible to compare one approach with another. “What if” scenarios just don’t work with project management. You really cannot predict what would have happened if you took a different approach. Even if you saw a decrease in defects after employing pair programming, how can you attribute the change to that practice. Perhaps this phase of the project was not as “complicated” as the last, resulting in fewer defects. Perhaps your team has become more knowledgeable and has learned from their mistakes. Who knows?

  4. Bret Anno said,

    I always love this discussion. Applying % to performance is like saying you are 90% done with what you are working on. Too many variables here – if you are questioning whether or not to do it – just try it.

    I personally think code reviews are a waste of time, but there are others who think differently (I will say when done right they are helpful though painful).

    I do not think that anyone who has spoken on this topic has disagreed with the notion that code should be reviewed in some manner. Let the developers decide review the code real time with pair programming or have a code review later. How many times has someone skipped having a code review because they could not schedule enough people?

    Also, we have had quad-programming sessions. Does the group work 4 times faster? No. Does the group understand the core piece of code afterwards? Yes. Is the code better than what a single developer would have done? Yes.

  5. Alejandro Germenos said,

    I think pair programming is a good technique when you are helping someone to catch up in a project. Also, when someone is less experienced, it is really useful to be beside someone who really knows what’s going on, and be able to ask questions (and, hopefully, help catching a bug).

    If both guys have the same amount of experience, and have the same time in the project, then I do think it is a waste of productivity.

  6. Mike Stump said,

    This is actually very true, and it can be effectively managed to actually raise that last 15%, as far as defects and bugs, by quite a bit. I have two developers on my staff that literally make up for the other’s weakness. We make new hire prospects take a short test that generally identifies their personalities in a professional environment, It is a really short test, about 20 questions, that identify four different traits. I’m sure you have heard or taken a handful of these. One of my developers is very high dominant, or lion and low detail. This one is very creative, and very systematic in his thinking. The other developer is very high detail and low dominant. He is the best at identifying that one little piece of code that might cause a problem with the finished product. He also is able to make sure cross browser support is the best it can it be. Together those two make an awesome team, they each bring a different personality to the table and the end product is absolutely phenomenal. So, yes Pair Programming can be a great tool if implemented correctly.

  7. Allan Cascante said,

    I definitely believe pair programming is yet another practice invented to solve problems that are not really there or are easier to resolve with careful and thoughtful design and work by the developers; pair programming productivity will depend in many factors as mentioned by David.

    I have seen people grabbing each other by the neck after a long pair programming session, for me is a hard to implement practice; lot of cultural issues to address and there are lots of other practices that can be implemented; to both increase quality and quantity; with less effort.

    At the end is a matter of taste…

  8. Anna Nachesa (née Chikalova) said,

    In my opinion, pair programming in XP way is very good approach when you have to do something very quickly, because in this case the observing programmer will at least easily spot typos and small omissions which the one who writes the code can miss (like the passenger in the front seat notices more than the driver because he is more relaxed), and two people working on the same problem motivate each other and help not to get distracted from the task (getting distracted from the task can reduce the productivity of a developer working alone even more than by 50%, by the way). Last but not least, working together is good for team-building.

    Another variant of pair programming is peer review, when the programmers review each other’s code after it has been written. I begin to think this might be the way to go for the projects where there are many developers involved, as it can help to spread the knowledge within the team, promote team spirit and reduce time for bugfixing. In this case, it is similar to open-source approach, when everybody can check everybody else’s code. Not sure if such things are easy to realize, because: 1) not everybody likes other people peeking into their code; 2) if there is time pressure, spending time on code review might seem to be a luxury; 3) it may degrade to a formal exercise; 4) there should be an easy way to communicate and/or track remarks about the code of another team member.

  9. Rob Humphris said,

    None of these agile ideas are sweeping rules… sitting people together only works if there is a clear need, and if one person can impart knowledge to another, or short cut the learning process for the other.

    Learning by example is the best way, but putting two headstrong know-it-alls together is like trying to teach a pig to dance… It wastes time and annoys the pig.

  10. Peter Rawsthorne said,

    All of the above…

    Short answer.

    Pair programming is one of the keys to achieving a shared understanding of the architecture. A shared understanding of Architecture is key to maintainability. This has a positive impact on the metrics within your questions…

  11. Mark Hord said,

    I think pair-programming makes code reviews and the loss of time associated with them unnecessary so there are trade-offs. Doing pair programming means skipping a lot of code reviews and the changes they bring late in development. But it does depend a great deal on the pair having people-skills and egos that allow it to work. Old timers have to accept that they can and will learn from newbies and newbies have to accept that the old timer might have good reason for doing things the way he does. It works both ways.

  12. David Höhn said,

    Is this a serious question? Even back in 2005 there were already studies published which quite clearly outline the benefit of pair programming. The XP Sardinia study underlines it even more. Feel free to message me for the papers.

  13. Mark Golczewski said,

    I agree with Rob that none of these are hard and fast rules. I’ve implemented pair programming opportunistically in my IT groups. As some pointed out, not all team members can work together indefinitely as a pair though to be a real Agile team, they should be able to pair up for shorter periods. That’s very powerful particularly when as Bret implied, there’s a real need for the team to understand what’s under the covers of a piece of code.

    To me pair programming is yet another tool in the toolbox.

  14. Adail Muniz Retamal said,

    The most used argument in favor of Pair Programming (PP) is that of the “online peer review”. I don’t think it’s correct in every instance, only in some cases. Inspection has been proved again and again as the most effective technique to find defects, even better than Unit Testing alone.

    I don’t recommend PP as a mandatory practice, but only as something to do when the developer needs a second opinion. In this case, it’s something that is natural to do and most people do this without even giving it a name.

    And if someone wonders how to go Agile without PP (and without many of XP practices), I recommend a look into FDD (Feature Driven Development), which was created independently and simultaneously to XP (1997-1999) and yields excelent results, without the negative feelings caused by XP, particularly to management.

    FDD relies on model and code inspections to ensure quality (and, of course, Unit and Integration Testing as well), and PP is usually not practiced.

  15. Bob Marshall said,

    Software quality is not just an absence of defects. My favourite definition of quality (selected from many, many differing perspectives: c.f. http://www.qualitydigest.com/html/qualitydef.html ) is Shigeo Shingo’s: “Quality is the absence of defects in a process” ( http://tinyurl.com/5e4h8j ), although I also have a soft spot for Taguchi’s (inverse) definition: Quality is the loss a product imposes on society after it is shipped”.

    Why does this matter and what relevance to pair programming? For me, it speaks to the core purpose of pair programming: to reduce the risk of defects – mainly, coding and “micro-scale” design defects) being injected – AND NOT IMMEDIATELY FOUND – into the product design under development. Does pair programming achieve this? Generally, yes. Can we think of better (more cost-effective) ways – either complementary or alternative – to the same end? Yes, too.

    Pair programming’s roots, as “peer code reviews turned up to 10″ – from XP – highlights the origins of the practice – continual peer review of code, as it is being written. Approaching pair programming from this (limited) perspective still looks to me like a form of testing to finding defects – and thus counts as waste in my book. Although, if we have to look for defects, then I agree that looking as close to the point of injection as possible – as pair programming should be doing – has to be the least worst option.

    More ‘progressive’ aspects of pair programming, such as ongoing training and coaching, exploration of the design space, identifying refactoring opportunities, etc. do however go some way to rehabilitating the practice.

    So what other – complementary or alternate – practices should we consider to reduce the wasteful aspect of of pair programming i.e. to reduce or eliminate its use as a means to find defects? I think that’s maybe a topic for another posting, but here’s a general question I have found useful in the past to get the ball rolling:

    “Poka-yoke or “mistake proofing” ( http://en.wikipedia.org/wiki/Poka_yoke ) is a fundamental Lean concept popularised by Shingo. By what means can we poka-yoke the process of developing software systems?”

    - Bob

  16. Jasdeep Singh said,

    We have been practicing pair programming for the last 4 years. Needless to say, we dont want to give it up. Senior management will always be skeptical to it since two people are working on the same task. However the management is also the first one to suggest that we should add more resources when a project is in trouble.

    The success of pair programming also depends on the team dynamics. Certain so called team players may not be fully inclined to doing it and this may lead to more pain than anything else.

    I dont want to repeat all the benefits of pair programming as mentioned in this thread since all of them are mostly true and pair programming is an extremely productive practice, however I would like to recommend a variation of it. We call it the “Complexity Based Programming”. Based on our modelling/design sessions for stories, the developers come up with tasks that either qualify as High or Low in complexity. Simplistically speaking a high task would need a pair to work on, and a low task can be done by 1 developer. This practice has been highy successful for us in gaining a little more momentum as well as appeasing the senior management, while not compromising on the quality of the product.

  17. Alexey Krivitsky said,

    When I am pairing I am not a semi-programmer, rather we both are making up a super-programmer.

  18. Marcello de Sales said,

    To the best of my knowledge, pair programming and peer review, as suggested by Anna Nachesa, can effectively be used in Agile teams, but i may depend in a lot of factors such as team maturity in the practice and/or in the technology being developed, or still when the team members decided to practice it. Moreover, as Anna suggested, developers doesn’t like to have others peeking into their code. Therefore, in my opinion, the “hidden-code culture” should be taken away of any Agile team, because pair programming (and also peer review) can be better applied when the artifacts are located in the same base line, say a Subversion repository, where all team members and others from other teams have the same visibility to the current code being developed. Mentioning also the use of any Product/Issue/Bug/ticket tracker system that can flag every team member about a particular code.

    So, I’ve participated in projects with highly experienced developers, where the technology being used is not a problem (say Java Enterprise Edition). However, the understanding about a new functional or non-functional requirement, say, a new architectural change decision, a new framework being adopted, a new code-convention, or the very confusing user story, could trigger the need of Pair Programming among the team members to better mature on that new requirement. In this case, I hadn’t seen no need for Pair Programming practices once each of the team members have enough understanding on how to implement requirements, an only in cases where those requirements are not clear. As Anna suggested, then, Peer Review practices would be applied without having 2 team members in the same code effort at the same time.

    Non-experienced teams can definitely use pair programming as per the use of the practices, but as mentioned before, the team matures in both technology, requirements, etc. In my opinion, Peer Review is a great tool when you have a team that uses the same base line of code. By using an Issue tracker, team members could just assign reviews to a given code, in this case, by sharing a Patch to an existing set of artifacts in the same base line. This is the most common and basic approach in Open-Source teams and, in my opinion, scales without any problem. Take projects like the Eclipse IDE without thousands of developers distributed in different teams around the world, who use a the issue tracker to “communicate” their tasks and request Peer Review. ( https://bugs.eclipse.org/bugs/ lists bugs, but it can also be used to track requirements). For example, you can enforce commits to the subversion repository, when one feature has been Peer Reviewed by at least 2 or 3 developers of the same team, just by sharing the Patch through the ticket system. This is a good policy when the Sprint is almost over, or that sprint is just before a MAJOR code release. This is a way, in my opinion, to ensure code quality and “almost bug free”, after all the reviewers have completed the reviews (by themselves, alone, as experienced developers), then the owner of the artifact/code being developed will commit the changes. There’s no need for a private meeting for peer reviews, as Anna mentioned and I agree it is just luxury time lost.Consequently , the use of Peer Reviews with Issue trackers can be an easy way to communicate and/or track remarks as Anna’s last notes.

  19. Dave Clack said,

    My take is somewhat different to many of the contributors here. I think most people would agree 2 heads are better than one with life’s most complex and intractable problems, whether technical, business or even emotional.

    At the same time I’d (virtually) never seek advice about what breakfast cereal to eat.

    So I guess what I’m trying to say is, using your intelligence to decide what to pair on will get the best results.

    Or maybe that’s self evident and I shouldn’t press “submit” – maybe I need a pair.

    btw I should say that I was a skeptic until trying, maybe i’ve been lucky with the folk I’ve had the pleasure of working with. We now use pairing for all sorts of stuff that are not sw engineering per se, business planning, forecasts, even marketing activities. For spreadsheets I find pairing is great – show me an xls without a bug !

  20. Jerome Pimmel said,

    At AOL and BSkyB the teams I was involved with through EnergizedWork were full-time pair programming and I would submit that the difference between pairing as an option vs mandatory pairing full time is of paramount importance in this discussion.

    The classic rule about “write no code which is not fixing a failing test”, can bear some parallels with pairing. Our teams adopted a team norm of “Commit publicly”. That norm has two key dimensions 1) Commit to the PO and each other to complete the work promised during that planning game. 2) Commit no code which you did not write collaboratively as a pair.

    When pairing is enforced and you cannot be seen to work alone, there is no hiding from your duties. Your mistakes – whether trivial typos or otherwise – should be caught out by your pair. Stories which you jointly complete must be robust and fit for purpose in one anothers eyes and resilient to the critical gaze of the next pair who might happen upon your work. You can more easily foster and engender collective code ownership. You are kept more honest, which puts the screws on laziness through duplication / copy paste, bad naming or non self documenting code, or otherwise avoiding refactoring where it makes sense to be absorbed then.

    When pairing is optional, the door is left open for individuals to prefer certain other individuals for pairing, or for pairing to be avoided, otherwise marginalised or put on hold completely in the haste and panic of a deadline, thereby allowing technical debt, more bugs and short cuts to be introduced into the system.

    This enforced pairing may suggest a harsh regimen, not so. Ours was one where an ideal pair day was established; 6.5 hours in a day where everyone would be expected to be paired up, working, switched on and fully on their game. This also meant fairly firm hours but no overtime, since you cant write or check in code by yourself. There were also two keyboards and two mice per station, so keyboard hogs could have control wrested from them.

    However the aforementioned are not the greatest benefits of full time pairing; these come from knowledge share. I have heard several leaders in Agile speak about generalized specialists and some comment that it takes so much training and effort to skill people in new disciplines, as if to say that its nigh impossible to hire or create them in “the real world.”

    Full-time pairing (which we applied to each of the following disciplines; DB admin, development, Sysadmin) enabled our team to develop cross-skilled members within a short (3-6 month) period with no interruptions for training. It fosters a culture where anyone can be both a mentor and the mentored.

    Furthermore, it aids in eliminating superhero culture, as nobody could seek to excel or go beyond the call of duty (imo hero speak for overtime) – any success was measured entirely at a team level. We employed weekly iterations with daily, sometimes half daily, pair swaps. Everybody was constantly being exposed to, held accountable for and felt responsible for, much broader and deeper areas of the system than just the code, the architecture and deployment.

    The BSkyB projects continue to leverage these successes 15 months on (latest update was here http://www.agileinaction.com/2008/04/people-do-pair-programming.html ). Also relevant to this thread is, http://www.agileinaction.com/2007/02/my-take-on-perils-of-pair-programming.html

    To those seeking hyper-productivity, pairing would be, in my opinion, key to achieving it. The net effect of continuously collaborating so closely, sharing more knowledge, skills and collectively owning more of the entire system and process, can lead to some serious hustle when done right.

  21. Lakshmi Teeka said,

    Pair programming works wonderful when a module to be implemented needs a multiple domain knowledge. 2 people bring in the right combination of skill sets to come up with the best module possible avoiding less bugs. Design will be more robust. One person catches up the error during implementation introduced by other person. Time to delivery will be reduced. Last but not the least, it brings out the best confidence in both the programmers.

  22. Ananthraman Laxminarashimmaiah said,

    You need to build a team that is cohesive and mature before you could try pair programming. I have seen pair programming work well in two instances. When you have a complex architecture/coding that require analysis/collaboration and when you have a new/junior person to be brought up to speed quickly. There are times when pair programming becomes counterproductive if you have folks working on trivial tasks.

  23. Dennis Hjort said,

    I have both good and some not so good experience with pair programming, and in my view, it really does help some projects. The project I’m currently involved in also do rotation of the pairs, so the if it is difficult to work with someone, it is just for a short increment of time, and usally atleast one of the people in the pair will learn something new.
    Also, one of the things I think is necessary is that the work is done in a respectful manner. Of course you should give your thoughts a voice, but instead of sounding overbearing, it usally works better if given as advice, instead of rules that you have decided.
    Again, as Mark Golczewski said “To me pair programming is yet another tool in the toolbox”, I agree. Even if the main development in the project is pair-programmed, we do have singel programming tasks, which lets us get “alone-time” programming.
    For me, I think we get faster forward, and with less faults when we do sit in pairs, as long as the people involved is just as willing to work together as you yourself are. Also, we don’t have any “software module ownership”, so noone feels as if parts the software written is “my child, don’t touch”, instead everyone has the overall feeling that if they find errors, they correct it instead of finding someone responsible for the problem. Yet another feature of pair-programming I think.

    Again, just my view.

  24. Angelo Hulshout said,

    I’ve never really applied the technique as described by the XP guru’s, but the times that I worked one piece of code together with a collegue were definitely times that we spotted problems quicker. Often, I’ve seen myself and others sit together to fix a programming problem – the plain fact that you have to explain to someone what you are doing alreayd helps you find the right solution.

    In practise, I hear most people say that they use that approach as well, and only in a very few places I’ve seen people do it on a daily basis.

  25. Nicholas Pilbeam said,

    I think it depends. In my experience, one of my teams starting up decided that pairing would be duplication and therefore create waste and decided not to pair.The first sprint went quite badly with much rework, defects and incorrect assumptions being made. At the retrospective, the team decided to try pairing to solve these problems. I am a big supporter of self-organising teams hence did not tell the team at this point to pair, the team decideded themselves to pair which I think it important in adoption of pairing. The next sprint was far more successful, high quality, faster and more enjoyable on the whole for the team and now the team pair on nearly everything they do as they believe it is more productive, fun and delivers higher quality. Most of my others teams also pair now due to the first teams experience and I genuinely believe this helps them.

    However…..

    It really depends on the type of people you have in a team (most importantly their soft skills), the culture of the team, department and company and the type of work the team members might be pairing on. These are variables that I feel may hinder or promote productivity through pairing. I have seen that when teams regularly mix up pairs depending on the task and mix of skills can be highly effective but it may be tempting to avoid this to just pair with your friend and not other team members.

    I think it is critical that the team themselves choose to adopt this practice rather than the ‘management’ telling the team to do so.

  26. Duncan Campbell said,

    Pair programming can work.. if it’s done well.

    My first experience of pair programming was not fun. We were pairing for too long at a time. Despite me being the less experienced developer at the keyboard I was not really learning from the experienced developer directing me.

    Pair programming may not be as successful at structural error detection as other code reviews because the other part of the pair can be too familiar with the designing of the application, so lacks impartiality and can be blinded by his own decisions.

    Good pair-programming practice says that you need breaks as it is very intensive. The less experienced developer should be the one at the keyboard so that they learn, rather than falling asleep watching the experienced developer, and the less experienced developer needs to be able to stop being a code monkey and engage with the experienced developer, take notes, experiment, etc. You should also rotate pairs regularly.

  27. Matt Rowe said,

    I’ve not had a lot of experience managing pair programming but these are some of the benefits I’ve seen; new team members pick up the product faster, healthy debate over the best approach to take, useful to motivate team members that may lag behind and better quality coding, not to mention a bit of old fashion competition. Our best example was cutting an estimate of 30 hrs down to 12 ( 6 x2) in recent times. In the team, we tried mixing some paring and some devs on their own, then rotating depending on skill sets to tasks.

  28. Ralph Johnson said,

    People who study programming tend to ignore personality differences, but I think they are important. Pair programming appeals much more to extroverts (using the Meyers-Briggs definition) than to introverts. Most programmers are introverts. The way we teach programming tends to select for introverts, and to discriminate against extroverts. The way most programming groups operate (everybody working by themselves in cubicles) is suited for introverts, and makes life hard for extroverts.

    I’ve talked to more than one person who quit programming because it was “lonely” and they needed to talk to people. They would have been much happier (and more productive) in an XP group.

    There is a lot more to pair programming than personality, of course. One of my friends who is fairly introverted spent half a year or so pair programming, and says it was both one of the most productive and one of the most tiring periods of his life. The advantages of pair programming are the same whether you are introverted or extroverted, but costs are different.

    I teach a software engineering class at Illinois in which the students all are required to practice XP, including pair programming. Some students like pair programming, some don’t. Like anything else, you get better at it with practice. Most people have trouble with it at first, but after practice they can see its benefits. Some people think it is wonderful. I haven’t done a careful study of it, but I bet the differences in how people feel about XP is related to their personality.

  29. Stephen Souness said,

    My most enjoyable and worthwhile pair programming experience was in a similar structure to that Jerome mentioned:
    - weekly iterations
    - fulltime pair programming
    - switching pair each day or half day

    The team was small and each member had a similar level of experience with the core technologies, but enough diversity in experience of the non-core technologies to make the development process double as a worthwhile learning experience for all.

    Sometimes I find that I come up with a solution to a problem partway through explaining what it is, so having someone actively discussing something with me throughout the day prevents the occassional “can’t see the forest for the trees” situations.

  30. David Corbin said,

    EDIT: The post below was formulated, but not posted yesterday…the comments above reflect similar results, but I was not awaqre of them at the time of authoring….

    My experiences with pair programming run the full spectrum. In summary, the vast majority of times it has not provided a net gain, but there have been a few instances where the results were fantastic (and I do not believe the project would have suceeded with out it).

    So what has differentiated these experiences…..

    The very best have been some occurances where I am paired with another senior developer on a task that requires strict attention to technical details and heavy conceptual work at the same time. In some of these (fondly remembered) cases, it actually involved me walking aoround the room, drawing on a white board, and giving verbal instructions. At the same time, the partner was concerned solely with the technical details of implementing my utterances and scribbles.

    Similar effects are achieved when one member has strong technical knowledge, while the other has stronger “problem domain” knowledge. Individually they do not possess all of the required information to produce a world class solution.

    Times when I have paired two juniors has often brought good results. I find this works much better than pairing a junior with a senior (more on that situation later). The “Thwo heads are better than one” principle applies here. If I find that the work results are becoming lopsided (they often do), then the pairs are shuffled. If a pattern emerges it makes “HR” decisions very easy.

    For the senior/junior situation, I prefer to treat this as a mentoring scenario rather than a pairing scenario. This results in a different dynamic and different expectations. In most cases the number of hours where they directly work together is in the 8-20 range per week. During the remaining hours, the junior person “plods through” the directed assignments, while the senior person either mentors another junior, or actually performs senior level work.

    OF course, these are just my experiences, but they have stood the test of time (the first example goes back to projects in the mid 1980′s – well before these methodologies were formalized).

  31. Bob Lupton said,

    Has anyone else tried pairing a developer with a tester to gain the same benefit in terms of the detection close to the point of bug creation. It seemed to work especially where changes were being made to an existing system which the tester knew far better as a pseudo user. Interested to here the opinions of other on this on

    - Another Bob

  32. Slav Kabachenko said,

    From my personal experience: if the pairing developers are on the same level of the expertize – waste of the resources/time.
    If you are not practicing the design/code reviews and Test First development(TFD), then pairing(two high level developers) can produce better quality software, but be prepared to pay more.
    TFD and the reviews will improve the software quality even in AGILE environment.
    Pairing is very useful for a knowledge transfer.
    Again, those statements are from a personal experience, and are not Hypothetically Speaking.

  33. Louis Tassé said,

    Pair Programming needs to be well applied. It depends on your software project characteristics. Basically, it depends a lot on the culture at work, the people, whether you have documentation or implicit documentation. Overall, I have used it very often (in a punctual manner and as a standard in the process) and it always allowed the results to get done faster and better. Or course, for some situations, it might need more follow up from the coach. And some staff are simply not suited for that.

    That’s why it certainly cannot be applied abroad blindly and must always be a case per case evaluation. I especially recommend it for teams that have a very high team spirit and for critical situation where there is a lot of unknown in the feature you want to implement. In those case, two people will work way better than having each of them in their own corner alone.

    Don’t forget that while they are working on the same task, both of them are giving an effort on it. And since software engineering is not something that can be evaluated on quantitative production result (we are not making boxes), “When well done”, It is obvious that about the same value is given from a pair programming activity that there is with having both of them working separately.

    It can be risky, but if you know your staff and your in control, then it’s a definite plus.

  34. Jeff Sutherland said,

    I work with two companies that do pair programming on almost everything (hundreds of developers) and they are two of the most productive companies in the world – 5x, 10x, and even higher than many companies I work with on all projects. So pair programming doesn’t slow you down.

  35. Bruce Eckfeldt said,

    Evaluation of pair programming needs to be discussed relative to the business value delivered. Two people working separately can write more code without a doubt; but that doesn’t mean they are providing more value to the customer.

    Some of the ways pairing adds more business value:

    1) Continuous code review to ensure that obvious, or not so obvious, mistakes are not being created that would introduce defects.

    2) Promotes code that is “readable” and greatly improves the long term value of a system by making it something that future developers can pick and start working with quickly.

    3) Creates a collective knowledge of all aspects of the code base which reduces risks and the flexibility of team members to work on all parts of the system.

    4) Discussion over implementation and requirements and a “double-check” of understanding of business needs. It’s easy for one person to misunderstand a customer’s needs, it’s more difficult for two people to misunderstand something in the same way.

    5) Energized work – pairing keeps the development moving and allows programmers to “spell” each other by taking turns driving.

    6) Pairing promotes the development of “simple” (but not simplistic) solutions that are easier to understand and tend to produce less code. This leads to less system complexity and overall size which allows new features to be added in the future with less work.

  36. João Cintra said,

    For me pair programming worked when I was on a project with a very tight schedule and the team start to get physically tired. We use the pair programming to reduce the number of errors and to try to reduce the stress on the team. It worked very well.
    I think there’s no formula to this technique. There’s no pattern showing us that it’s time to use it.
    Reading the above comments I saw a lot of different cenarios using the same technique, so I think we must have present that this exists and use it when makes sense.
    Final note, I don’t think it’s a waste of time when it’s well applied.

  37. Dave Aronson said,

    My two cents: I’ve only tried it a few times, but it worked well for me. WIth one guy in particular, it was even fun! He had a similar sense of humor, skill level, attitudes re How Things Should Be Done (including that something different but still good was fine), etc. We also each knew a lot of little tricks (C, vi, Linux, shell, make, programming, whatever) that the other did not, so we each learned a lot that we could reuse. However, I can easily see how it would work poorly for certain other pairs. That guy reported that most of the others in his office, absolutely hated the experience and refused to do it any more. It definitely requires people who can give and receive criticism graciously. Toastmasters and other such leadership training can help people develop these skills.

  38. Kevin Schlabach said,

    Pair programming can work and can pay off these dividends, but several things must be in place and it is not easy.

    The team has to work like a team. It has to be able to handle conflict. Tools need to be in place to allow mature engineering practices. Pairs should switch constantly. Co-location is critical. It has to be eased into (can’t be an all or nothing thing to start). Various levels of skill and domain knowledge increases its value. The team should be at least 4 people (two pairs) to allow rotation. A coach that can lead by example is critical in showing how it should be done and prove that it can be enjoyable.

    Pair programming is easy to get wrong. I suggest it is the last of the XP practices to try since it is so fragile.

  39. Meyer Rozengauz said,

    All comments above are more or less positive and I have to agree with them. I used to practice pair programming a lot and it always gave a great result. We always got better solution than each of us could come up but his own. Pair programming with a proper partner is like making something with 2 hands and not like doing something with one hand and something else with another.

    You have an issue of productivity. Yes, for simple tasks you will loose 50% or even more, so, don’t use it for simple tasks. With wrong person you will loose 90% productivity, so, don’t do it with wrong person “just to do pair programming”. But for complicated tasks you don’t loose productivity at all. Even if the pair finishes project slower you will save time on bug fixing. The most important thing here is there are projects that can be done well by a pair in reasonable time but cannot be done at all if they work not together on the whole thing but on different parts of it. I worked on project like this.

    I’m not practicing pair programming any more for several years. Why? I have no proper pair-programmer. There are some great programmers around but non of them is my pair.

  40. Patrick Welsh said,

    Pair programming is absolutely not waste, neither in the short term (expressed in labor costs), nor in the long term. Quite the contrary, pairing reduces the defect risks, and increases the rate of continuous improvement, that together reduce the truly staggering costs of bad software delivered to production, rotting code, and the downward spiral of bad faith between customers and development teams. Speaking as an experienced solo-programmer and pair-programmer, I can say this with absolute conviction. One of my premier criteria for a new developer candidate is their aptitude for pairing — for spotting when the pair is blocked, for spotting when the “driver” is slipping on practices or making a bad choice, for doing continuous testing, design, and refactoring as an ultra-high-bandwidth conversation between two highly focused programmers.

    In the enterprise software dev environments in which I work, agile teams are increasingly asked to handle more and more projects, business domains, technology stacks — you name it. And all of this happens in a context of ginormous existing legacy codebases. For the average enterprise team, the effort required Herculean, and the results often feel Sisyphean. Pairing is essential to addressing all of this.

    Defect risks arise from far more locales than the object model — we find defects all the time lurking in differences in deployment targets, in app server configurations, in un-tested database-resident biz logic, in requirements misunderstanding — again, you name it.

    Enterprise programmers must “know” far, far more than ever before. More business rules, more technologies, more specific codebases, more integration details, more process details. For a given story card, it is exceedingly rare that an individual programmer can “know” all of what is required to test-drive an implementation without defects, design flaws, and requirements misses, at a high enough rate of production.

    Only with pairing do my teams have a prayer of spreading required knowledge quickly and effectively enough. Only with pairing do I see risks being systematically reduced, and continuous improvement steadily improving. Only with pairing do I see high quality at steady, high production rates.

    Only with pairing can I learn, BTW, which of my team members are just not skilled enough to keep pace. Nothing separates wheat from chaff like pairing them a few times.

    I have tried dev projects many times both ways: with pairing and without. Regardless of your agile blend and agile context, if you are working in a complex enterprise SW dev world, you likely need more pairing, not less. The risks you thus avoid, in my experience, far outweigh the apparent short-term increase in labor costs.

    I question, BTW, most of the research done so far on this. I think we have mostly crappy methods of measuring long-term productivity that takes into account overall defects, code debt, overall production capacity (how skilled and knowledgeable the team is overall), turnover costs from burnout, production losses from context switching, etc, etc.

    Before I seriously entertain discussions about how valuable pairing is, I personally want to see a far greater swath of the enterprise developer community actually capable of doing it well.

  41. Ashley Ternes said,

    I think that Dave Clack has offered one of the most common sense views on this (and there are a couple others along the same lines). We’ve seen teams suffer under a regimented pairing scheme (forced pair changes based on time) and I’ve definitely experienced unproductive and even very destructive code reviews (junior developers reduced to tears by arrogant and aggressive seniors). Paired programming can at least give a shared sense of ownership that actually facilitates a better working relationship between senior and more junior developers. This, of course, is dependent on the culture of the group and the desired outcomes. Like most aspects of software development you should be asking yourself what you are really trying to achieve. If you are seeking to write as much code as you can in a short period of time and you have very experienced people, then you could argue that they should pair less. If quality is more important, or you wish for more junior developers to learn from experienced heads then get them pairing. If you have the luxury, pick your teams accordingly. For the most part, we try to choose teams that consist of developers who pair very effectively and as a matter of course. This is because we have a long term view to development and we need the team to be flexible enough to work on almost any part of the code base (not to say we don’t have “experts” in certain areas but the impact of them being away or unavailable is mitigated).

    Common sense….

  42. Donald Lawn said,

    Nobody codes well for a full day anyway. I consider 4 to 6 hours a day of hard slog to be very good. Much of the time is otherwise taken up with thinking, communicating, etc. and sadly with rework.
    Pair programming helps meet the needs for socialisation, thinking, and reduces rework.

  43. Nate Kirby said,

    I am more in agreement with Chris & Tim. Personally it seems that having QA trail the iteration makes it so you are not sure when things are actually completed and that makes metrics planning and setting expectations hard.

    We use week long iterations and inside of a week we plan design implement and QA a small set of features. Yes, Naresh points out that it looks like mini waterfall, but we include daily scrums, deploying people where they are most needed, test driven design and it yields a highly productive and very agile process.

    We started with 2 week long iterations, but found the meetings to oppressive, it seems 1-2 hours of planning for an iteration yields about 1 week of work and it seems that 1 week iterations are the sweet spot for our team. We have been doing this for 2 years now with a lot of success.

  44. Vicenç García-Altés said,

    I think pair programming increases the quality of the product so much. You have two people thinking about the same problem and discussing about it, so the solution they found will be better. One programmer “controls” the other work ensuring that they accomplish the programation rules of the group, make all the tests they have to do and so on. Based in our experience I really encourages all the people to use pair programming.

  45. Lee Tambeau said,

    I have found that the quality delivered is far superior to that developed without it and the impact on productivity has not been significant especially when considering the savings from producing a quality deliverable. However, it takes developers who are not thin-skinned and can leave their egos away from the keyboard. It’s not for everyone.

  46. Chad Steele said,

    Paired programming is great for short bursts of debugging or mentoring, but I don’t recommend it as an ongoing management strategy. Social dynamics will eventually cost productivity. People either get a long too well or not well enough, either way the relationship gets more energy than the code.

    A better strategy is cross-functional regression-test (XRT) development.

    In short, you write code, someone else writes the regression test.. and you write the regression test for another developer. In other words, everyone supports each other by developing regression tests for each other’s code. Nobody get’s out of writing regression tests and the culture of checking each other’s work through automated testing is collaborative… it rarely devolves into competition because everyone is transparent.

  47. Jane Prusakova said,

    Pair programming is excellent for both knowledge transfer and when coding something non-trivial. The quality of the code written by two people is better, with fewer defects to fix down the road, and better interfaces and readability for later maintenance. Test coverage also is better when done in pair programming mode.

    However, a lot of the code is relatively trivial, and having more than one person to write it is both wasteful and leads to over-engineering and extra complexity. I find that on the average 10-12 hours a week (that’s about 2 days) spent pair programming is usually enough, more is too much.

  48. Neelesh Vaikhary said,

    It works well if both the developers are extrovert and have same pace..if you pair the mismatch it’s disaster. Again as Jane mentioned, most of the coding is pretty trivial these days, so having 2 senior deveoper to do pair programming is waste..may be good if you are writing some highly scalabe backend component. I have personally made it work with junior engineers just to mentor them. If that’s the goal, I highly recommend it. Again the code is a as good as the programmer(s) writing it, process only helps.

  49. cspag (Chris Spagnuolo ?) said,

    RT @jamescarr: Another way to pair programm across geographical boundries: http://etherpad.com/ More on pairing: http://is.gd/8cgP

  50. Chris said,

    Thanks for all of the contributions to this lively discussion.

    @Alan Griffiths: I really like your idea of pairing a dev with a tester. Do you do this now and how does it work for you?

  51. Todd Britson said,

    Hello Chris, I am not certain how Alan pairs them up if it is a one-to-one or not, but I thought I would let you know how I do it. We start the iterations with a complete team (test, dev, doc, etc..) and the developers start coding and the testers start writing test cases. However, I found it very useful to make sure the stories are worked as they are prioritized, meaning grab the first few stories assign them off and then complete them before moving on (of coarse you need to all some exceptions). These usually makes people step out from their own comfort zone and help one another. If the developer can not move on to the next story until that one is completed then he will help test, test it. The developer will either sit there assisting with setup and execution or help test another story (one he/she did not develop) be tested so that story is checked off and another can be started. This approach I find to be very affective but does make an agile coach work a little harder to stay on top of it all.

  52. Audrey Troutt said,

    From a developers perspective pair programming is wonderful when both parties understand how to pair effectively and the task at hand warrants two brains instead of one. We often pair two experienced developers together in these cases and I can say from definite experience the amount of time saved by avoiding “stuck time” is significant. We also get less distracted by email, unrelated news articles and the like. Plus, we are consistently rigorous in following our code and testing standards (when alone it is easy to make up excuses to let this or that tiny case slide, etc.). Because of pair programming the bus number for our projects is higher, which comes in handy when a client has a new request and one or more of the developers are busy on another project.

    The times when pairing has been a disaster is when the other party is unfamiliar with (and even suspicious of) the practice. Then it really does become 2x the cost or worse, plus it feels terrible.

    We don’t pair as a rule, but we are careful to evaluate whether it is needed for each story.

  53. Ilias Jennane said,

    What we’ve done at our company is a mix of both.
    We pair program once a day for an hour usually after our standup meeting.
    30 minutes each.
    With a daily rotation.
    The real goal, rather than just code quality is to try to eliminate code ownership, and have shared responsibility over code .
    thanks :)

  54. James McGovern said,

    Pair programming works when you have competent IT professionals. It is a waste of time if you are trying to do this in India…

  55. John Chappell said,

    I’ve found pair programming to be of great value in promoting knowledge sharing within the team. A less experienced developer paired with a more experienced one, the less experienced one has an opportunity to learn a lot – however, you have to have the right team culture to do this.

    Open communication is absolutely vital. Without a culture of openness, pairs may fall into a position, as Eric Johnson has described, where one resents the other’s greater insight. We found that it was important to ensure that it wasn’t always one member of the pair who ‘drove’.

    There are times, however, when pairing just doesn’t give the results which its apologists trumpet. The worst case I’ve seen is a super-fast developer paired with a very slow developer with the result that the super fast developer took a week to do something that would normally have taken him solo 2 days to do (even allowing for bug fixing time, it would have been completed and QA clear in a maximum of 3 days). It’s important to pair people together who are fundamentally compatible, and not assume pairing will always give better results.

    Some people are also natural loners, and they have their uses too. It will not automatically help (whatever their level of competence) to force them to work with others.

    Finally, we had some interesting and good results pairing a coder with a tester. It isn’t something to do all the time, but it really helps, especially when writing unit tests, and in our case, doing UI coding, to have that extra “I bet I can break it this way” mentality on hand, to suggest extra things that developers might naturally overlook. For this, though, you need good QA people, and they are hard to come by.

  56. Ken Daly said,

    Personally, having been through large telecommunications companies down to very small 8-12 people companies. I put “zero” defect firmly on the side of unrealistic expectations. Now, a target of having “zero” defects found by customers, that you didn’t already identify internally, is a very aggressive goal as well, but one the Development/QA teams should strive for. The balancing act of time, cost and quality is very real, but can be managed with the knowledge that you have measured your quality and are accepting the risks with your eyes wide open. So to answer your question, companies around the world do ship software, knowingly, with defects. How they manage that risk, provide support, manage corrective content in their iterations and how they improve as products are adopted and mature, it what separates the successful from the failed.

Add A Comment

 


Creative Commons License
©2011 Edgehopper.com. Please don't copy me, it's bad karma.
Edgehopper by Chris Spagnuolo is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.