Against 100% Pair Programming
Vivek Singh has an interesting post talking about the problems he has found with pair programming. In an excellent pliant manner, he points out that he is not totally against pair programming, but that he has come across some flaws which he can’t ignore.
To quote Vivek:
… once I have come up to speed with codebase and I am not making too many mistakes, which needs to reviewed in realtime, I think its time to stop pairing 100% of time. Now this stage is reached too many times in project but we do not recognize this and we stop being agile.
on August 2nd, 2006 at 7:35 am
Paired Programming and Pliancy…
Software process improvement isn’t about making peole happy, it’s about making better software. I believe in "software as a team sport" mainly because I’ve played many organized sports and I’ve been involved with software teams. I can eas…
on August 2nd, 2006 at 7:56 am
The question isn’t whether or not pair programming works at all. The question is whether or not it is always appropriate to use. I go back to what I said a while back. Pair programming (or any other technique) is neither sufficient nor necessary for successful software development. I know this because I was involved in a couple successful projects (millions of user interactions, 99.99% up time, very low defect rate, high development velocity) where we used pair programming maybe 10-15% of the time. Remember PSD isn’t about not doing techniques. It is about thinking about what your context and only doing something if it makes sense for you and to a degree that makes sense for you.
on August 4th, 2006 at 10:15 am
Lidor has some further thoughts on the role of pair programming in a software development practice. Basicly he says pair programming doesn’t replace code reviews and you don’t have to choose between them.
Let me reiterate… there is no silver bullet. It will be the combination of your context, your people, and the techniques you choose to implement based on your context and people that will determine success rate.
on August 7th, 2006 at 10:54 am
We definitely team up to write the trickier pieces of code. If nothing else, working with someone else that I trust watching gives me confidence that we’ll miss far fewer details. Basically, the typist ends up thinking primarily about the more immediate details while the buddy thinks about the somewhat larger picture.
Essentially, we team up as pair programmers when the work is significant enough to benefit from the increased attention to a larger scope that two cooperating minds can offer. But we tend to do it only for the serious core libraries that you really don’t want to frig up. For everything else, we do the less-resource-intensive steps of having all code changes reviewed by a peer familiar with the system (which implies that at least two people are familiar with each system) and have all new software go through a real 2-4 h code review (which implies that we don’t write pieces of software that take more than 2-4 hours to review [hmmm I should post about that idea]), albeit sometimes several weeks after it’s ”done”.
on August 8th, 2006 at 10:53 am
This is an interesting subject. I read Vivek’s post, but unfortunately comments are closed. I put my comments on my blog instead.
I think the key value-add practice here is collaboration. Pairing is definitely the tightest form of collaboration for code development, but there’s ample room for variation.
Brad Spencer describes a variation in his comment, above. Personally, I don’t think that’s optimal, but I can see that it would be effective enough if that’s the level of collaboration his team can support.
I think it’s important to avoid extremes, and I think that’s basically consistent with the theme of this site. Ironically, one extreme that people are susceptible to is to become overly dogmatic in their reaction to agile extremists: “(a) I don’t like agile extremists. (b) Agile extremists like pair programming. (c) Therefore, I don’t like pair programming.” Slipperly slope, that.
on August 8th, 2006 at 11:00 am
Dave,
You are right that dogmatic reaction to agile extremists is a slippery slope. We are very aware of that slope and so you won’t see arguments like you proposed on this site. Yes, I don’t like agile extrememists and yes Agile extremists like pair programming. But it does not follow (at least to me) that I don’t like pair programming at all and I don’t think we’ve said anything like that on this site. If we have, it was a mistake and goes against the whole point of pliant. We don’t want the Agile community to stop implementing the techniques they want to implement, we just want people to consider their context before they go headlong into implementing a new process or technique.
on August 8th, 2006 at 11:53 am
I completely agree about the importance of context and the value of flexibility in adapting our methods to the circumstances of each project. What’s a bit puzzling is why anyone thinks that’s any different from what “agile development” already means. All the things people are talking about under various names like FlexDev and Pliant and so forth are just reformulations of the basic ideas of the agile movement.
The backlash is really against inaccurate or loose usage of terminology arising from a misunderstanding of concepts, and is not a disagreement about fundamentals. Changing the buzzwords doesn’t fix the misunderstanding. If people are moving away from fundamentals, it might be better to try and bring them back on track rather than just to invent new buzzwords.
If a new buzzword like Pliant becomes popularized, you can bet that vendors, consultants, and pundits will be on it like flies on cheese. (Yes, flies like cheese, too. Or so I’ve heard.) We’d soon see ads for PliantDraw. If that happens, shall we have another backlash and start another website? I’m not so sure that coining more words to describe the same concepts is an effective way to clarify matters.
on August 8th, 2006 at 12:12 pm
It’s important to remember that I offered an example what I do as something that works for me (so I continue to do it).
At no time do I actually evangelize that you also do the same. I merely described that, yeah, we do that (and have been doing it long before I ever heard of Agile anything, FWIW). Collaboration might be the worst thing your team could do. That’s the point. Do what works. Don’t do it just ’cause I do. But it helps to hear about what I do and why, because I presume you know how to adapt anything useful you might learn to your own situation.
I don’t think any of us actually go around claiming to be “doing Pliant” development. I’m definitely not aiming to create another buzzword factory. We don’t want to popularize Pliant; we just want to say we understand that different situations call for different solutions and actions, and we don’t appreciate specific general-purpose solutions, but we do appreciate good ideas that we can steal.
on August 8th, 2006 at 12:15 pm
First, Pliant is inherantly not marketable. We don’t endorse any techniques for your software development, we don’t try to tell people how to develop software, we don’t get upset if people choose to employ one technique and not another. There is nothing to sell. There is perhaps two paragraphs worth of writing needed to describe all of PSD. (I’m quite surprised we’ve managed to munge it over and over and repost the same thoughts again and again on this site). Like Brad said, we may share what works for us, but that is with the understanding that it might (read, probably won’t) work for you unless you adapt it to your context.
Second, the meaning of “agile development” _is_ now controlled by the vendors, consultants and pundits and no longer means what it used to. In many cases it has become a dogmatic approach to implementing 12 particular techniques spurred by the bottom line of book publishers and conference promoters. Hence the need for a new term. We thought a clean break would be easier than getting the horse back into the barn.
on August 8th, 2006 at 1:26 pm
I don’t disagree, except that I’m not ready to accept the idea that vendors, consultants, and pundits have taken control of the terminology. They’d like to do so, of course. There’s nothing to sell with agile, either, although people who are selling things have picked up on the popularity of the buzzword. That happens again and again in our industry.
What you have written here isn’t any different from the basic principles of agile development. The agile manifesto as such doesn’t specify any development practices, it only lists a few guiding principles. The points you raise about sharing ideas and adapting them to your own context is just plain old agile stuff.
I like the general idea of this site, but I don’t know if we really need a clean break just to separate ourselves from commercial interests who want to co-opt the terminology, because new terminology is likely to cause more confusion than it clears up.
Maybe it’s just that I’m simple-minded by nature, but when I come across five or six different terms for the same idea, and five or six different camps arguing heatedly about what the terms mean, and it all sounds like the same basic stuff over and over again, I get confused.
I do appreciate the overall focus on adaptability and value. Keep up the good work on that front.
on August 8th, 2006 at 1:38 pm
Sorry, one small additional point. You mention collaboration might actually be a bad practice in some circumstances. I’m having a little trouble visualizing that.
Can you help me understand when collaboration would actually be counterproductive? What sort of situation do you have in mind (other than a one-person project)? Can you share an anecdote about a real-world project where collaboration caused difficulties; a project where better results could have been obtained if stakeholders didn’t work together very much?
I’m really asking a plain question here, and not trying to make trouble. If there are cases when collaboration doesn’t help, then I need to understand how to recognize those cases.
on August 8th, 2006 at 1:51 pm
We agree with you that the ideas are more important than the terminology. That’s kinda our whole philosophy :) We had to call the site something.
As far as when collaboration may be a bad idea, I don’t know when that would be, but I’m willing to accept that such a context may exist. That’s the whole point! We don’t presume to know what’s best for you! So, sorry, I can’t offer you a checklist of when you should avoid collaboration. That’s precisely the kind of prescription we are saying doesn’t work.
What I can offer is past examples of things I have done, why I have done them, and what the result was. But it would be arrogant and presumptuous of me to imply to try to convince you that you should do the same thing and that you will get the same results. I may recommend that you try something, but I won’t tell you that it will definitely work. I’m glad you’re asking these questions, though, because it’s forced me to think more about the aspect of giving advice and sharing experiences. For me, I always trust someone who’s relaying experience over someone who’s evangelizing or selling a cure-all, and maybe that’s what bothers me the most about today’s Agile.
on August 8th, 2006 at 2:50 pm
>I’m willing to accept that such a context may exist.
Well, okay. Speaking of context, remember what prompted people to start exploring alternative approaches to software development in the first place. It was the low success rate of traditional practices, especially what we now call the linear waterfall approach, and all the stuff that goes along with that.
One of the core problems with traditional methods was the lack of collaboration. That, and other core problems, caused people to re-think what works (or doesn’t) and why it works (or doesn’t). Once you start discarding these core ideas, you’ve moved away from the original idea of agile development and (possibly) getting into a realm that has no definitions at all. Sort of an “anything goes, nothing really works better than anything else” mentality.
>But it would be arrogant and presumptuous of me to imply to try to convince you that you should do the same thing and that you will get the same results.
I disagree. If you can provide objective arguments in favor of using any particular practice, then it behooves me to listen. It’s not arrogant at all for you to explain why something works. We’re all building software, after all. If something adds value to that process in one situation, it’s very likely to add value in another. If not, then we need to understand exactly why not so we will know when to apply that particular practice and when not to. That’s a bit more solid than just saying, hey, this worked for me but it might not work for you.
Some of the principles and practices that underlie agile methods have come to be accepted through the collective experience of practitioners, based on what has worked on real-world projects. I submit the reason you can’t easily think of a concrete example of a case when collaboration would be a bad idea is simply that there is no such case. This is one of the foundational definitions of adaptive development, including agile, lean, and other variants. It’s a direct answer to one of the core problems we’re trying to solve in our profession.
I’m not so sure literally everything is totally open. I think there are certain basic concepts that differentiate agile development from other approaches, and if we set those aside then we’re left with, effectively, no definition or no framework at all.
I say this as someone who has a personal interest in understanding the hard value of agile practices, specifically in contrast to traditional (waterfall) practices. Sure, there are situations where agile methods don’t apply. But once you’ve identified a situation as appropriate for agile methods, then the next step is to apply those methods properly.
It’s the same idea with any other tool. To tighten a Phillips-head screw, you choose a Phillips-head screwdriver. It’s the right tool for the job. Once you’ve determined it’s the right tool, then you need to grasp it by the handle and fit the tip into the screw head. Otherwise you’ll fail to tighten the screw, and probably hurt yourself as well.
Similarly, once you’ve determined agile is the right approach to a given project, I think it’s best to get as close as you can to the most rigorous agile practices, given the realities of the project and the people you’re working with. That way you can achieve the best results.
I understand and appreciate your reaction to the overselling of capital-A agile, but I hope you won’t go too far and throw out the baby with the bathwater.
on August 8th, 2006 at 3:04 pm
A power drill with a Phillips-head bit works just as well at tightening a screw. Whether you choose to use a screwdriver or a power drill depends on the material being screwed into, the size of the screw, whether you have ready access to a wall socket etc. In short, choice of tool depends on your context.
on August 8th, 2006 at 3:06 pm
Also, I think you misinterpreted Brad. Yes, it is good to show people what has worked for you and explain why it has worked for you. However, assuming that the transfer of knowledge will lead directly to success for the people you tell, having known nothing about their project or their people, is arrogant and presumptuous.
on August 8th, 2006 at 3:47 pm
ZOMG.
Me: But it would be arrogant and presumptuous of me to imply to try to convince you that you should do the same thing and that you will get the same results.
You: I disagree. If you can provide objective arguments in favor of using any particular practice, then it behooves me to listen.
You’re arguing that I need to evangelize to you and try to get you to do things my way? I am confused.
on August 8th, 2006 at 8:15 pm
Re: Power drill.
Fine. The point (and I think you know this perfectly well) is to choose an appropriate tool and then to use it properly. Be careful not to drill through your hand. And should the drill or screwdriver actually work “for you” (as opposed to “for screws”), be sure not to be so arrogant as to suggest the same tool might work for a different screw, or in the hands of a different person.
Re: Show people what has worked for you.
Sometimes its just a question of what has worked “for you,” and sometimes there’s more to it. Certain development practices have been proven effective on many projects. They don’t just randomly work sometimes and not other times. They work “for software development,” in the same sense as screwdrivers (and similar) work “for screws,” not just “for me.”
Flexibility is great. It means you can recognize that not every software development practice fits every situation. But once you’ve determined a practice fits a given situation, it fits just like a screwdriver fits a screw. It fits the same “for me” as it does “for you.” And if it doesn’t fit, it’s for some objective reason, and not just because it didn’t happen to work “for me.”
Re: Evangelizing.
No. Just explaining objectively. If a practice tends to be useful for software development, then there are reasons why and there are ways to understand and discuss those reasons. Similarly, any given practice will have its limitations and there are ways to understand and discuss those limitations objectively.
Otherwise, one would be surprised time and again by every outcome, because one could not correlate effect with cause based on experience, like one of those unfortunates who has no medium-term memory function (they can remember their childhoods and they can remember new information for a few minutes, but then they forget the new information, and every time they hear it it’s new to them again). It isn’t evangelism to explain how something works.
I’m reminded of deconstructionism. When I was in college, it was fashionable among literature professors. An unfriendly summary of deconstructionism might be to say it reduces any and all texts to the same level. The best works of Shakespeare or Dostoyevsky would be seen as no better than a grocery list. You could analyze the grocery list and discover just as much satisfaction and personal growth from it as from any other text. It’s an approach to literary analysis that totally misses the point of any given work of literature by reducing it to a string of words with no context and no relationship to past or future.
Your approach to software development appears to be similar. You seem to want to avoid identifying practices that might produce better results on project after project. If something worked once, that’s nice, but you can’t or won’t take any useful message forward from that success. All development practices are seen as qualitatively equivalent, and their relative value is reset with the beginning of each project, as if no one had learned anything about how or why the practices worked well or didn’t work well on previous projects.
I agree with much of what you’ve written here, but not to that extent. That kind of thinking is just too extreme and too limiting for me.
on August 8th, 2006 at 8:25 pm
Woah, not sure where you got the idea that we can’t or won’t learn from past projects. We definately learn from what we’ve done in terms of what works and what doesn’t work on a particular project. What we don’t do is then go blindly into applying the process used on Project A (the successful one) on Project B. We evaluate what went right in Project A, consider how Project A and B compare and contrast and then apply the processes we think will work. Then we iterate on the process as Project B progresses.
And we certainly aren’t going to go around telling people what they should do without any knowledge of their project, their people, their company culture, their goals, and their definition of ’success’.
on August 8th, 2006 at 8:28 pm
I am simply staggered by the fact that you think we are too extremely anti-extremist.
And BTW, here’s a post I made earlier today in followup to a different thread on the site, tongue-in-cheek.
Then you say this:
Are you serious? That’s so not me or how I do things that I am honestly flabbergasted. I learn from my experience and make new rules of thumb and build new processes and set new standards and apply lessons learned every day. That’s how our shop independently ended up coming up with a very agile-looking mode of building software all without ever having heard of it before. We found it after the fact and went “huh, these guys do a lot of the same things we do”.
But I do not think that you should use my rules of thumb and my processes that I built from my experience just because they worked for me.
I just don’t understand. I’m yelling “don’t copy me” from the rooftops and you keep yelling back “but I want to”. I guess I should yell ”learn from my stories and decide for yourself so you can be a strong and independent developer”.
on August 8th, 2006 at 8:55 pm
I guess we’re mutually flabbergasted, then. Who said anything about telling people what to do “blindly?” That’s a very different matter than identifying practices that are effective under specific circumstances, understanding just why that is so, and then using that knowledge to choose the practices that fit various situations and adapt those practices appropriately to each situation.
I don’t intend to use anyone’s rules of thumb “just because” they worked for them. I do intend to use practices that have been demonstrated effective generally, and I intend to understand how and why those practices work so I will know when to apply them and how to keep things on track when they aren’t working well.
I also want to understand how various development practices affect the financials of a project and the cost of ownership of the resulting product, as well as how to introduce process improvement in traditional organizations to help them adopt better practices. I have to go beyond “it worked for me” to reach that stage.
No, I don’t want to “copy” you. I invite you to explain how, why, and under what circumstances your methods work so I can learn from that.
Meanwhile, I apologize for misunderstanding your point of view. I still think we’re generally in agreement about most of this.
on August 8th, 2006 at 9:06 pm
Indeed it would appear we are generally in agreement. Hazaa!