Discussions

News: How much pair programming is cost justified?

  1. Beyondng.com has posted "How much pair programming is cost justified?," a blog asking about when pair programming pays off in a development environment, suggesting that pairs aren't necessary when the team members agree on conventions and the algorithms aren't complex.
    When as long as, all the team members are agreed on the name of functions for validations, dialogs, etc. Why we need two people to write this code? Will the code be too complex that we can not change it later on if the writer leaves the team? Will pair programming have great (if any) effect on the code quality? So I personally believe that Pair Programming should be done when we are doing something which is not trivial. What do you think?

    Threaded Messages (48)

  2. I agree. Pair off programmers so they can collaborate and bounce ideas off each other (each programmer should have their own computer & be able to see each other's screen easily). Works wonders for the tougher problems, and I'd argue even makes them both more productive. However, both programmers should have their own set of features to complete, and will do just find working alone for the more trivial features. All in all, my theory is, "pair them, and let them decided when to work together and when not to".
  3. You'd be surprised at what kind of mistakes can be made while doing "trivial" code. Usually it's the poor junior developers who get lumped doing all the "trivial" code too which makes it even more likely that they'll make mistakes. I'll give you this point, however, if: * All of the requirements are fully documented up front and are correct (if they're wrong, it could be beneficial to have more than one person decide why they're wrong). * The implementation is fully documented * The backend service API is fully documented * The implementation strays in no way from what is considered "trivial" and this is understood up front (it has to be understood up front otherwise the developer may provide a "trivial" solution to what is in fact a "complex" problem). * You're confident that at least one other developer will be able to fully understand the solution by looking at the documentation and code * You're confident that your developers understand what a "standard" solution is for the problem. * You have some measurable way to determine that everyone is following the standards (e.g. code reviews etc.). * You're confident that the developer will make few enough errors for the cost of those errors not to be more than putting another developer on the problem. and that's just for the trivial problems.
  4. This reminds me of something that happened a few years back when working with an experienced developer who doubted the value of unit tests on "trivial" code. I used a small tool to generate some tests for getter and setter methods on a class - methods that were supposed to be trivial. Lo and hehold, I discovered 3 copy & paste errors in this trivial code! Had that developer been pairing with someone, the likelihood of missing those errors would have been almost nil. There's also a great paper by Arlo Belshee from the Agile 2005 conference about Promiscuous Pairing, in which he details his studies on the most effective ways to use pairing: http://www.agile2005.org/XR4.pdf#search=%22Promiscuous%20Pairing%22 or http://tinyurl.com/hzht2 In my experience, there have been a couple of times where a divide and conquer approach with single developers worked well for short periods of time (note that the developers were all senior level with at least 15 years experience). However, those occasions were few and far between and we paired much more often than not. Pair programming may cost some up front, but when it's used properly it pays off significantly in the end. Dave Rooney Mayford Technologies http://www.mayford.ca
  5. Lo and hehold, I discovered 3 copy & paste errors in this trivial code! Had that developer been pairing with someone, the likelihood of missing those errors would have been almost nil.
    Maybe, but it's also likely that for all the rest of the code, the pairing would have been detrimental since the two developers would have been less productive. Besides, the error you found could also have been found with testing, which is -- again -- much less costly than pair programming. Errors happening in trivial code are not impossible, but they are very rare, so why would you base your entire development methodology on these cases? Statistically, it doesn't make sense. -- Cedric http://testng.org
  6. Pair programming may cost some up front, but when it's used properly it pays off significantly in the end.
    I read this a lot from Agilists, but I have yet to come across one shred of evidence for this claim, and even if you can probably name a few such projects, there are at least that many that tried and gave up. -- Cedric TestNG
  7. Evidence[ Go to top ]

    Pair programming may cost some up front, but when it's used properly it pays off significantly in the end.

    I read this a lot from Agilists, but I have yet to come across one shred of evidence for this claim, and even if you can probably name a few such projects, there are at least that many that tried and gave up.
    Here is what I have experienced personally as both a developer and coach:
    • Testing - When people are pairing, they're more likely to work test-first, or at least write tests
    • Small Coding Errors - A second pair of eyes will almost always see the small errors such as the copy & paste problem I mentioned in an earlier post, as well as simple errors such as using '=' instead of '==' in Java
    • Coding Tangents - A pair is much less likely to go down a rat hole than a single developer because they're collaborating on the design. Having two people working together means that questionable designs are caught early and either dropped outright or changed
    • Cleaner Code - Having a person navigating helps the driver keep in mind the more strategic aspects of development. A second person can focus on how a particular method within a class fits into the whole of the system. The result is small methods in small classes with less coupling. This fits in with the notion that pairing should only be used for complicated code. My question is, why is it complicated? Having someone to navigate often prevents needless complication, at least in my experience.
    • More Time Coding, Less Debugging - Rather self-explanatory, for all the reasons I've listed. I've seen this first-hand.
    • Cross-pollination - When a team is pairing properly, i.e. they're switching pairs regularly, everyone knows something about everything. That isn't to say that some people aren't experts in a particular area, but it does mean that the team's Truck Number is mich higher (which is a Good Thing).
    If you don't believe me, just ask me. ;) Dave Rooney Mayford Technologies http://www.mayford.ca
  8. Re: Evidence[ Go to top ]

    Hi Dave,
    If you don't believe me, just ask me. ;)
    Well... No offense, but... no :-) I was only mildly surprised to see that your company specializes in delivering XP and Agile software, so that doesn't really make you very objective (I don't claim to be either, but at least, I'm not making any money if I'm right :-)). Anyway, on to your points: - Testing might be more likely when there is a pair, but it's not unlikely with good developers either. Testing is a mindset, and a conscientious developer will always write tests, whether in pair or not. - Errors/Debugging/Cleaner code, etc... All of these points can easily be addressed by a simple review system, like I've seen in many places. Even a simple email-based review mechanism (say, at check-in time) works wonder, and while I can buy that pair-programming will give you more rapid feedback, I don't think it is significantly better to justify the price you pay for pairing your team. I wrote more about code reviews here. There are a lot of adverse environmental factors that make Pair Programming something that is far less useful than advocates claim, and I wish that people who defend this approach were a bit more honest and admitted them instead of always saying "It works! And if it doesn't work, you're not doing it right"... -- Cedric TestNG
  9. Re: Evidence[ Go to top ]

    There are a lot of adverse environmental factors that make Pair Programming something that is far less useful than advocates claim, and I wish that people who defend this approach were a bit more honest and admitted them instead of always saying "It works! And if it doesn't work, you're not doing it right"...
    Cedric, What is your point? You are right. Pair programming done badly isn't worth it's salt. But then again anything done badly isn't worth it. I don't think anyone is denying this. The problem here is cultural I believe. I don't expect to get value from anything until I've gone through the learning curve of knowledge->understanding->skill. And I don't expect to become instantly skilful just by reading a book. If you take the time to gain a deap understanding of pair programming by learning through example from a skilled mentor then you are truly in a position to evaluate it's worth. You are also in a position to experiment and vary things a bit with side-by-side programming, lone programming when apropriate, or even a few embelishments of your own. Untill then you just don't have the skill to make it work, and crying out for evidence won't change that. In the Agile world they call this learning through doing. Outside of software this is how much of the world learns. No black and white and no definitive proof. Just idioms and practices of skilled, experienced and respected individuals who then pass them on to others through example. If you haven't got a skilled and respected pair-programming mentor, then I suggest that you find yourself one and suspend judgement. I'm sure that after pairing with such an individual for a period of time that you'll get all the evidence and proof you need. Paul
  10. Re: Evidence[ Go to top ]

    +1 for pair programming, not necessarily all of the time, and it needs to be with the right people. But... pair programming with an idiot does one thing, it keeps you from surfing to TSS, or looking up some unrelated stuff, or checking news. It keeps you on track like nothing else I have experienced, and for this reason alone, I support it wholeheartedly. yes, of course, you can make "if you were a real professional you would stay on task" arguments until the sheep come home (Im from NZ!), but I believe that people arent that disciplined all of the time, or even half of the time. And it is so easy in this job to get diverted onto things that seem relevant but... just arent. as a criticism of pair programming, which will in many cases be enough to kill it: It increases the requirements for skilled people, with people skills. Ie, your workforce becomes more difficult to find. but if you can find those people...? I believe its the way to go. cheers Greg
  11. Pair programming may cost some up front, but when it's used properly it pays off significantly in the end.

    I read this a lot from Agilists, but I have yet to come across one shred of evidence for this claim, and even if you can probably name a few such projects, there are at least that many that tried and gave up.

    --
    Cedric
    TestNG
    About agile in general: http://www.theserverside.com/news/thread.tss?m=c.reply&thread_id=42423#219080
  12. I used a small tool to generate some tests for getter and setter methods on a class - methods that were supposed to be trivial. Lo and hehold, I discovered 3 copy & paste errors in this trivial code!
    So you're saying "small tools" can be as effective as pair programming? Neat!
    Had that developer been pairing with someone, the likelihood of missing those errors would have been almost nil.
    ..oh
  13. Has anyone tested continuous pair programming with professionals? From my understanding the only study ever peformed was with 1st and 2nd year CS students, whom I can totally imagine would be more productive in pairs. I've never felt my productivity ever approach the 200% of what I normally produce that would be needed to justify the cost, except in cases where the two programmers had unique knowledge that neither possessed individually but was needed to solve a problem at hand. Bryant
  14. What an old argument...[ Go to top ]

    What an old argument ... "Pair programming" is only for "hard things", where the inerently complexity of the code requires 4 eyes and (possibly) 2 working brains :)
  15. Re: What an old argument...[ Go to top ]

    I think that implementing some (changing) requirements is like building a house in a tree. You always need to go up and down for tools and to check your plans (probably some sketches). Thus, the road from the big view to the tiny implementation details. I find it hard sometimes to get out from implementing some low level algorithm to see the big picture again and get to the next major step. Beside that, when working with someone else near you, you are not so tempted to read an article in the middle of your task or listen music etc. :-) You simply focus on what you have to do. And, at last, the feeling of being part of a team is much stronger. This may help you when on the base of an ugly, home grown framework or something like this.
  16. Re: What an old argument...[ Go to top ]

    Beside that, when working with someone else near you, you are not so tempted to read an article in the middle of your task or listen music etc.
    You are not a good General if you have not trust and primarily are not able to inspire your soldiers ...
  17. Yes, we have measured pair programming with seasoned professionals. We found that we are in fact twice as productive when pairing, which means there was no cost associated with pair programming. I blogged about it awhile back.
  18. Yes, we have measured pair programming with seasoned professionals. We found that we are in fact twice as productive when pairing, which means there was no cost associated with pair programming. I blogged about it awhile back.
    From your blog:
    I‘ve seen the research that indicates this just isn‘t true.
    I must've missed something here because I'm still finding it pretty easy to be skeptical of the theory that having two people work on something is twice as efficient... -- Les Walker
  19. Stanford is currently doing a controlled study with Bay Area software engineers, having them solve programming problems in a lab, using both paired and unpaired test subjects. I'm eager to see the results of this study, personally. A friend who has participated blogged about it here: http://twoalpha.blogspot.com/2006/05/pair-programming-experiment-at.html James p.s. Last I heard they were looking for more people to run through their tests. Contact information is available at the link if someone is feeling motivated. :)
  20. Your friend write in his blog: "During my pairing session this past weekend we talked a bit about the notion that once we humans have a goal we often have a strong impulse to start acting towards that goal, without necessarily doing much planning or testing - like driving nails before deciding where, exactly to drive the nails, and that we continue with our actions without doing much checking if we are in fact heading towards our goal." Perhaps that is why I have never adopted pair programming. I have notice that whatever I do (even driving nails) I usually whant to plan and prepare more than others. XP also has the idea that you should not plan ahead but instead solve the immediate problem and the refactor which is against my natural instincts. This would mean that the unsatisfying answer is that pair programming and XP works for some and not for others. /Björn
  21. Well, if we assume the perfect development environment with all top-notch developers, then yes, I agree Pair Programming probably has a low ROI. For the rest of the world though, the following benefits to me show a ROI in short and long term. These benefits are: 1)Two pairs of eyes on the code. Yes, I understand that a pair of terrible coders will still produce terrible code. This also isn't an excuse to not do code reviews with the team. To me team code reviews should be coarse grain dealing more with design/functionality than syntax details. This is where the extra eyes on the code comes in handy. The pair code review can be very fine grain and catch the small problems that code can have. 2)Increases involvement. That is, as a single programmer, there are times where you are either way off task or just plain stumped. By having your pair with you it is more difficult to go surf to digg or slashdot. Thus your personal daily involvement with doing work increases. This isn't saying that productivity goes up, just the involvement with your work. I feel that is an important distinction to make. 3)Rapid learning. Pairing should allow a more open communication between people of different skill levels. Because of the increased involvement, each person is more acceptable to learning new things. When the mind is focused and engaged learning is much quicker. 4)Higher actual time. A single coders actual coding time per day is not eight hours. It is more along the lines of 2-4 per day. This is due to the numerous other tasks that we handle along with whatever meetings we attend. By pairing up, each of the coders are committing to a chunk of time to work. I find it harder to interrupt two people working hard on a problem than a single person. Thus the actual time doing productive work goes up when pairing. I'll finish up with stating that pairing is NOT for everyone. It isn't that they don't see the benefits, it is that they just don't like doing it. To me this is fine. In no way should it ever be forced upon a team. I would much rather a full team try it out and buy into it than have one person shove this technique down the team's throat. However....I also think that everyone should give it at least a couple of weeks when trying it out. One day or a couple hours isn't enough for a test run. Aaron Korver The Curmudgeon Coder
  22. 2)Increases involvement. That is, as a single programmer, there are times where you are either way off task or just plain stumped. By having your pair with you it is more difficult to go surf to digg or slashdot. Thus your personal daily involvement with doing work increases. This isn't saying that productivity goes up, just the involvement with your work. I feel that is an important distinction to make.
    Never thought of that. +1. The most believable argument I've ever heard for pair programming. Just add TSS to the list of sites.
    4)Higher actual time. A single coders actual coding time per day is not eight hours. It is more along the lines of 2-4 per day. This is due to the numerous other tasks that we handle along with whatever meetings we attend. By pairing up, each of the coders are committing to a chunk of time to work. I find it harder to interrupt two people working hard on a problem than a single person. Thus the actual time doing productive work goes up when pairing.
    I agree but pair programming doesn't address the underlying problem - that people seem to ignore the need for focus on intellectual tasks.
  23. Pair programming improves the productivity for one reason that now there are two minds working on a problem, and sometimes its very beneficial in keeping tab on deadlines and not miss on being productive, especially during early days. In my current project, I am working alone on a module, and deadlines being kinda not so stringent, I am hardly making much progress on a daily basis. If I had a pair, then probably we would have done more progress as tendency to sit idle or doing something irrelevant reduces.
  24. Pair programming improves the productivity for one reason that now there are two minds working on a problem, and sometimes its very beneficial in keeping tab on deadlines and not miss on being productive, especially during early days. In my current project, I am working alone on a module, and deadlines being kinda not so stringent, I am hardly making much progress on a daily basis. If I had a pair, then probably we would have done more progress as tendency to sit idle or doing something irrelevant reduces.
    This is my experience too. There are a lot of benefits to pair programming I could mention, but when done right I find that pairing is very intense. At the end of a day pairing I'm often totally exhausted. Paul.
  25. Pair Programming is...[ Go to top ]

    Hi All, Came across this post on a Smalltalk blog and thought it was pertinent to this discussion:
    Post by Micheal Lucas-Smith Pair Programming is where some guy next to you nags you until you program the thing properly.
    Comment by Troy Brumley and it is not Where some guy sits next to you and tells you how to drive the keyboard. "No, no, do a control-c, don't use the mouse" is not what pair programming is about.
    I think that sums it up nicely :^) Paul.
  26. Pair programming is just as efficient, as it prevents people from surfing and making posts to TSS. I am off now to Slashdot... regards Malcolm Edgar http://click.sourceforge.net
  27. A few comments bring up some very good points in favor of pair programming. However, if we are working with programmers that are the kind the agile method recommends -- that is to say they are self motivated, competent, and well-led -- then it seems like a pure pair programming approach is overkill. Especially if you are working with a small team (like 3-5 programmers). Best work enviroment I have been could perhaps be best described as "pair programming, but with two computers". When either of us had problems, we just looked over and asked. Collaboration was easy, and occured very often. When it came time to implement what we agreed was best, we both went back to coding. Each of us decided when something warranted collaboration and when it was not necessary (which should be a pretty easy decision if egos do not get in the way). Junior programmers, new people to the team, or anyone else with little experience I would consider an exception -- pair programming may be good for a bit as a training style. But this discussion is more about broad team generalities than corner cases.
  28. A few comments bring up some very good points in favor of pair programming.

    However, if we are working with programmers that are the kind the agile method recommends -- that is to say they are self motivated, competent, and well-led -- then it seems like a pure pair programming approach is overkill. Especially if you are working with a small team (like 3-5 programmers).

    Best work enviroment I have been could perhaps be best described as "pair programming, but with two computers".

    When either of us had problems, we just looked over and asked. Collaboration was easy, and occured very often. When it came time to implement what we agreed was best, we both went back to coding. Each of us decided when something warranted collaboration and when it was not necessary (which should be a pretty easy decision if egos do not get in the way).

    Junior programmers, new people to the team, or anyone else with little experience I would consider an exception -- pair programming may be good for a bit as a training style. But this discussion is more about broad team generalities than corner cases.
    +1 I agree. Alistair Cockburn refers to this approach as side-by-side programming, and like pair programming it has it's strengths and weaknesses. I've done both along with lone programming. It is a matter of judgement when to apply each. Agile is not about rules, but about skills. My concern is that programmers slavishly stick to one approach without taking the time to develop the required skill in the others. What ever you do must depend on your team and your circumstance. But for the most difficult of programming tasks where I need maximum focus and maximum intellectual capability, I find that pair programming with a trusted partner is by far the most intense and productive (results generating) approach. Not all pair programming occurs infront of the keyboard BTW. Some of my best pair programming episodes have occured when we both got into a muddle and decided to break-out and think through the problem over a coffee. You just can't do this in the same way with side-by-side programming. Paul.
  29. my experience[ Go to top ]

    Just to share some of my experience as a senior developer: pair programming is very effective in these areas: 1. discuss/describe problem (especially with increased complexity of the problem) to your peer. Usually you and your peer will have different insights into the problem because each looks at the problem from a different angle. Sometimes even the existence of a listening person is enough to help. 2. debugging/fixing hard bugs, the peer contribute not only intelligence, a lot of times also team support in that you are not stuck here youself. 3. modifying code in a place where you are not familiar/comfortable, the peer is very helpful in pointing out your mistakes and providing immediate feedback on the code quality. In these situations I think pair programming is 1+1 is far greater than 2. You might notice that #1 is not writing code, it's more about communication of ideas on designs. But I think that's a very important aspect of programming. I would say I spent about 20~40% of time do pair pragramming. I need time alone too, for example, read TSS to keep up with the technologies. More importantly, I also need time to focus on a problem myself, after doing that I would usually go to a colleague to validate my thoughts. I found these think-alone-discuss-with-peer cycles very effective in solving problems and avoiding design mistakes. I usually implement the design alone (40%~60% including thinking alone).
  30. Not justified at all[ Go to top ]

    How much pair programming is cost justified? None. I have seen that practice implemented more than once, and have yet to see the so-called benefits. I see it as a complete waste of time, as anything that goes against the way people are used to writing software. Instead of trying to force people to pair, or to practice TDD, why don't these agile ayatollahs concentrate a little more on how projects are managed. In my experience, the biggest problems with software development today are not programers, but the so-called "upper management" and "architects" (sigh). Try pairing managers or architects for a change, instead of trying to convince us (through mostly biaised studies) that changing the way we program is beneficial. I saw more "agile" projects go down the drain than non-agile ones. Of course, the XP gurus have the answer ready: it was done "poorly". Ever wonder WHY most of these were done "poorly"? Wouldn't it be because these practices are mostly unrealistic?
  31. Simula Research Laboratory has done a very nice work to invistigate Pair Programming. Take a look at: http://www.simula.no/departments/engineering/publications/Arisholm.2006.2
  32. ..And here's a critical look at some of those researches, which investigate possible bias through choice of sample, Hawthorne and Placebo effects: http://www.hacknot.info/hacknot/action/showEntry?eid=50
  33. ..And here's a critical look at some of those researches, which investigate possible bias through choice of sample, Hawthorne and Placebo effects: http://www.hacknot.info/hacknot/action/showEntry?eid=50
  34. Pair Management[ Go to top ]

    Pair your managers, so that when one of them starts to get up out of his seat to go ask a developer a stupid question, the other one can sit him back down and suggest he send an email instead. When one manager thinks up a cool new feature and wants to run to the developer to tell him to make it so, the other manager can ask whether he has a use case (or set of use cases) for the feature. When one manager hits Start -> Programs -> Microsoft Project, the other manager can quickly close it. Ditto PowerPoint. When one manager schedules a meeting, the other manager can come up with an agenda. etc.
  35. Re: Pair Management[ Go to top ]

    +1 if it works the way you describe. -1 if they get into a contest on who can come up with the shortest schedule, grandest claims, and schedule the most useless meetings.
  36. How much pair programming is cost justified? None.

    I have seen that practice implemented more than once, and have yet to see the so-called benefits. I see it as a complete waste of time, as anything that goes against the way people are used to writing software.

    So your criticizing a study because the people doing it MIGHT be biased, yet you provide your own bias as anecdotal evidence?
    I have seen pair programming implemented more than once, and I have seen it fail more than once. I have also seen it work more than once. If your project does not do refactoring, and does not do unit testing, pairing will probably have a negligible effect. However, I have yet to find someone who does these things who does not benefit from pairing. This however is anecdotal evidence as well.
    Now, if you want a study that does not provide a bias towards agile practice I would suggest studies about how people work in pairs in general. Do they tend to benefit from the interaction or does it slow them down?...What the suggestion for pairing in Agile is all about is that there is an overwhelming amount of evidence that most people work better in pairs on complex problems. And programming is most defiantly a complex problem. People with forms of Autism however tend to have trouble working in pairs, and it may not be as beneficial for them. (I don’t mean this as a dig. A good friend of mine delt with these types of issues and. Pairing didn’t work for him as it does for me.)
    The good news is if all these Agilests are wrong, then Pair programming will go away and you won't have to worry about it. History has a way sorting these things out. But you might ask your self if your own distaste for pairing might be coloring what is quite an extreme viewpoint on the issue.
  37. Re: Not justified at all (I love irony.)[ Go to top ]

    I think one of the big issues with discussions of all aspects of agile methodologies is that people tend to state things in absolute terms. eg: pair programming has to work all the time otherwise its useless pair programming will not work for everyone. it will not work all of the time. I think we can all agree on that right? the interesting question is, whether there are benefits to pair programming? (by benefits, I mean that it outperforms solo coding in either quality, time, or monetary terms). Tough to find evidence for or against. Studies can be criticised (not realistic, biased, we dont do that here, I just dont like it) so, if there are no studies we can trust, we have to accept anecdotes and make tentative conclusions based on those. so heres my anecdote: I consider myself a programming rock star. Unfortunately, my enormous ego makes me investigate difficult problems that may only be vaguely (or not at all) related to my current problem, and also makes me spread my gems of wisdom to people at TSS and others, as well as write emails, and surf technical sites to improve my prodigious knowledge. Basically, having a pair stops me stuffing around. It also stops me getting too close to a particular problem. I dont like pairing all the time, particularly with a person who is slower than me. But even then, I find I do only what I need to. I dont read email, I dont surf the web, and you wont see me at TSS. Now, you could discount this anecdote and consider me an anomaly. Thats fine. But... to do that, you need to add an opposing anecdote to our collection of anecdotes so we can all make an informed decision. PS. Your partner MUST KNOW HOW TO SHOWER EACH MORNING!!!! (and no, im not kidding) cheers Greg
  38. I consider myself a programming rock star. Unfortunately, my enormous ego makes me investigate difficult problems that may only be vaguely (or not at all) related to my current problem, and also makes me spread my gems of wisdom to people at TSS and others, as well as write emails, and surf technical sites to improve my prodigious knowledge. Basically, having a pair stops me stuffing around. It also stops me getting too close to a particular problem. I dont like pairing all the time, particularly with a person who is slower than me. But even then, I find I do only what I need to. I dont read email, I dont surf the web, and you wont see me at TSS.
    Here's my question: In the long term, is someone who pursues tangent, gets "too close" to the problem, and spends an inordinate amount of time reading technical sites more or less productive than someone who stays on task? I'd say it's entirely dependent on the person and the work he does. If I don't have "complex enough" work, I tend to invent complexity. simple CRUD application - maybe I should completely refactor this open source web framework? Or Hibernate? There's a nice simple system for you...it will keep my busy for months... Here's this research paper on... Not exactly agile. But give me a problem that others view as intractable and I'll obsess over constantly until I come up with a practical solution. It takes all types to develop software.
  39. So your criticizing a study because the people doing it MIGHT be biased, yet you provide your own bias as anecdotal evidence?


    Nope. I said there WERE biased, as there are no hard evidence to support their claim. And I wrote about my own (anecdotal?) experience which comforts me in my (humble) opinion that it's all a bunch of crap.
    I have seen pair programming implemented more than once, and I have seen it fail more than once. I have also seen it work more than once.
    Great, so it succeeds sometimes, and fails sometimes...as do other projects. I fail to see the big added bonus then?
    If your project does not do refactoring, and does not do unit testing, pairing will probably have a negligible effect. However, I have yet to find someone who does these things who does not benefit from pairing. This however is anecdotal evidence as well.


    We didn't wait for agile gurus to do refactoring, nor testing. However, the subject here is pair programming, not other agile practices.
    Now, if you want a study that does not provide a bias towards agile practice I would suggest studies about how people work in pairs in general.
    As I was trying to point out, most of the studies I've seen are biased one way or another. But feel free to point to one that isn't.
    What the suggestion for pairing in Agile is all about is that there is an overwhelming amount of evidence that most people work better in pairs on complex problems.
    There is an overwhelming amount of evidence that COLLABORATION between developers make them work better on complex problem. Which is not the same thing at all.
    People with forms of Autism however tend to have trouble working in pairs, and it may not be as beneficial for them. (I don’t mean this as a dig. A good friend of mine delt with these types of issues and. Pairing didn’t work for him as it does for me.)


    Still not resisting the temptation of blaming the failures of what you're proposing on some mental deficiencies of people trying to apply your rules?
    The good news is if all these Agilests are wrong, then Pair programming will go away and you won't have to worry about it. History has a way sorting these things out.
    Wait and see.
    But you might ask your self if your own distaste for pairing might be coloring what is quite an extreme viewpoint on the issue.
    I merely pointed out that I didn't find any evidence, nor in so-called studies, nor in reality, that would prove that pair programming works. iF that makes me come out as an extremist, so be it.
  40. Pair programming justified IMO[ Go to top ]

    Groklaw, TSS, Slashdot gets less attention. When you solve some low level problem keeping momentum is easier because either you or co-pilot will remember what you planned to do next.
  41. Too many cooks spoil the broth. Its as simple as that. I definitely believe 2 brains are better than one. But thats when we are brainstorming, coming up with ideas - ideas that are in the nascent stage - where one may not find faults - but the other one may or may be throwing ideas and speaking out loud. 2 or more brains are useful for whiteboarding exercises to check the validity of a design. I and peers do it often. But when it comes to implementation, I'd already have a solid idea and I'd just like to sit and implement. My brain thinks differently than the other person and pair programming would be obstructing my (and his/her) productvity. Lets face it - No two brains think alike. Peace, Srikanth
  42. Not justified[ Go to top ]

    I think the productivity benefit depends a lot on who is pairing. I've seen 2 guys together from a certain agile software house sit there and talk nearly all day about which one of the latest patterns they are going to use and what to refactor while all they had to do was fix a typo. If one of those guys had been sat next to someone with a grip on reality the job would have been done in 5 minutes. The only instance in which I have found pair programming to be productive is one in which you have a tedious job to do which is very error prone. For straight coding of average stuff it's a waste of resources. One guy sits there typing while the other is bored out of his/her mind. The guy next to you who has virtually lost the will to live is not going to add any value. I also think that pair programming is intrusive and unnecessary for solving difficult problems. A lot of programmers work via insight - you slog away at a problem for an hour, get absolutely nowhere then you go have a smoke or a coffee and suddenly you get a eureka moment and you rush back and code it up in 5 mins. Pairing is counter to this working style. Having some guy next to you whose brain is in a different gear just gets in the way as you are continually explaining yourself (or vice versa). Not that I'm cynical or anything.
  43. Re: Not justified[ Go to top ]

    I also think that pair programming is intrusive and unnecessary for solving difficult problems. A lot of programmers work via insight - you slog away at a problem for an hour, get absolutely nowhere then you go have a smoke or a coffee and suddenly you get a eureka moment and you rush back and code it up in 5 mins. Pairing is counter to this working style.
    I can't think and talk at the same time. Judging by the meetings I sit in neither can anyone else. I suppose trial attorneys can...but what does that have to do with programming? Heck, I can't think and have someone looking over my shoulder.
  44. Re: Not justified[ Go to top ]

    Seems to me that you're still missing the point: If pair programming involves complete changes in the way we're used to program, and only works SOMETIMES, what good is it? And what REAL evidence do you have to back the idea that it really solves more problems than it creates? I mean, you're the one supporting the idea of completely changing how we do our job. The burden of proof is on your side.
  45. As a relatively older programmer, I find the idea of pair programming with sharing of keyboards etc. is f**g stupid and I would shove this methodology up any MBA or PHB's butt if it is ever introduced into my organization. Now that I have got that off my chest -- It is always easy to blame programmers -- we are the only ones who can deliver something that can be benchmarked, measured and actually used. (Unlike the freaking deuchebags who specialize in selling asinine concepts like this ). However, instead of focusing on programmers, we should try examining shortcomings of project managers. IMHO, regardless of the methodology used, the bigger issue is of project management -- requirements creep, change request and most importantly -- budgeting time and resources. If the budgeted time is too short, expediency takes precedence over best practices. If enough time is budgeted for peer reviews, writing extensive junit and integration tests, demos for business folks and budgeted extra time for incorporating feedback , then most iterative style methodologies would work. Except pair programming -- that is just insane and would probably lead to the stuff I mentioned above.
  46. How much pair programming is cost justified? None. I have seen that practice implemented more than once, and have yet to see the so-called benefits. I see it as a complete waste of time, as anything that goes against the way people are used to writing software.
    and...
    As a relatively older programmer, I find the idea of pair programming with sharing of keyboards etc. is f**g stupid and I would shove this methodology up any MBA or PHB's butt if it is ever introduced into my organization.
    Me, too... 1974... punch cards... ring a bell? I'm old. Sigh.... I do and coach agile project management, now. Mostly leave the engineering practices debate to the developers themselves. When coding, over the years, I've paired and worked solo. I like both. More importantly, I'm waaaayyyy past the "little bit of knowledge" part. I can sort of tell whether pair programming will help a team in a variety of circumstances, how to tell if it is working, and what other practices can sensibly produce similar benefits for the team as an alternative. (It is the productivity of the team we are talking about, right?) Like many have noted above, I've tried more things that haven't worked than have, I just don't try them for long before helping the team adapt and move on. We (the team) don't get paid otherwise. In fact, I have an intro talk for development teams that want to try "agile" approaches called "That Won't Work". I say to them, "I'll describe a half dozen things that will make you happier (and more productive) as a team. When I do, you will tell me, 'That won't work!'". People don't like to be thought of as predictable, but as soon as I start to talk, they start squirming and in short order, someone bursts out and says, "That won't work". When they do, I ask them if they'd like to a) keep on doing things the way they have been, b) try out their own new idea, or c) try the agile practice that they say won't work. Usually they opt for a) or b). But it gets people talking about change. So what I really teach is the visibilty and feedback practices that let a team figure out for themselves if a practice adds value (usually by trying it). I certainly don't feel the need to cram a study down their throats. I show what evidence and arguments there are (as flawed as they may be), describe my experience of the practice in similar situations and trust that if they try it, they'll find out for themselves if it helps. I have a lot of other "agile" tricks in my bag if it doesn't. Finally, pair programming is pretty low on my list of practices to introduce (at least at first) when a team wants to be happier and more productive. For some reason it generates a lot of heat and noise. ;-) What I see in practice is that as a team gets happier (and more productive) using an agile approach, they tend to use more pairing (in coding and design).
  47. your list[ Go to top ]

    Forgive me for posting in this way, but I couldn't see a way to just contact the author directly. Peter, Have you published your list anywhere? I'd be interested to see it. If it's one of those deals where giving that up affects your livelihood and you'd rather not, I understand. Just thought I'd ask. Thanks, Alan
  48. Hi Peter, This was a great and reasonable response, free of the vitriolic arguments that characterize topics such as this. As somebody also requested, if you can show us your "bag of tricks", it would be really great. I am generally interested in the factors that enable successful use of Agile practices and factors that could derail such projects. Regards Sridhar
  49. Like always: it depends[ Go to top ]

    This thread is highlighting the "it depends" argument as it relates to when you use process and when you don't. Nobody likes to be forced into whatever the latest flavor-of-the-month approach is, so if you don't have buy in from your troops on pair programming or anything else you constantly are balancing efficiency/accountability vs personal freedoms and possibly productivity. The leader/manager/boss of the group really needs to keep a pulse on what the people writing the code are willing to tollerate in the name of tracking schedules and trying to help increase effectiveness without introducing what might be perceived as needlessness.