31–40 of 41 posts
This guy describes a really common antipattern I've seen with pair-programmers, call it "Workstation Chain Gang". This is where all work is done sitting side-by-side at a computer, and the only times you get up are for the bathroom or eating. The best pair programmers I've worked with will often do things like: say "let's take a walk" and then talk through design problems, get up and use a whiteboard, say "I want to…
This guy describes a really common antipattern I've seen with pair-programmers, call it "Workstation Chain Gang". This is where all work is done sitting side-by-side at a computer, and the only times you get up are for the bathroom or eating. The best pair programmers I've worked with will often do things like: say "let's take a walk" and then talk through design problems, get up and use a whiteboard, say "I want to…
What a fucking nightmare. Whether what he did was or was not Official Pair Programming (tm) is beside the point. Obviously, some people will thrive having to interact with a partner all day, every day, while others will wither. Requiring all your developers to work in this style is just nuts. It's like requiring all your developers to wear size 31 jeans.
I don't have any experience with Pair Programming as it is typically prescribed by "agile" project managers, but from my understanding of Pair Programming, I believe that there are more cases like this where Pair Programming doesn't work than there are cases where it does work. I've also run into a fundamentally flawed hiring scheme at every company that uses Ruby on Rails in which I am flat out not considered if I d…
This sounds like sample error. It is true that RoR culture overlaps with pair programming/XP culture and agile culture, but there are VERY MANY RoR places that do not pair every day.
In my place, I sort of enforce pair-programming for about 2 weeks before a deadline. Basically at crunch time. I basically believe that crunch time increases the probability of errors by orders of magnitude. Secondly, as the author mentions, that is the time when gaps in knowledge need to bridged over... at the expense of personal ego if need be.
> In my place, I sort of enforce pair-programming for about 2 weeks before a deadline. Basically at crunch time. I basically believe that crunch time increases the probability of errors by orders of magnitude. Code reviews will give you the same benefits without the soul crushing drawbacks described in the article.
Plus code review has an inherent context switch (for the reviewer) that is even worse during a crunch time.
My own take: if it works well, do it. If it doesn't, do something else. Repeat. But your bottlenecks in the larger world tend to be talent, time and cash (though the latter is becoming less so in software development). If you have (enough of) those, use them and ship, get profitable, and anything procedural or paradigmatic should be far down your list of priorities.
You have to combine it with TDD or else each person focuses on something different, and basically reverts to being a spelling mistake checker until it is their turn.
I have only enjoyed it when doing mostly new development, in a modern language with modern tools, combined with a strict red green refactor process, where one person writes the test , and the next makes it pass and writes the next test.
For more exploratory stuff, or doing it without TDD, or using old crappy languages and tools, or doing maintenance, it just sucks and I prefer to work alone.
Earlier quoted context omitted.
> First, pair programming has to be between near-equals, or it just doesn't work. That depends on what you think the goal of pair programming is. > If one person knows a lot more than the other, most of the time is spent in training. Which is part of the intended effect of pair programming. It forces everyone to share their knowledge with everyone else both about programming, and about the code base. This brings new…
In this case, though, the pair was limited to the abilities of the weaker member.
Earlier quoted context omitted.
> In my place, I sort of enforce pair-programming for about 2 weeks before a deadline. Basically at crunch time. I basically believe that crunch time increases the probability of errors by orders of magnitude. Code reviews will give you the same benefits without the soul crushing drawbacks described in the article.
For a short, intense period of time - pair programming can produce the same benefit as code + code review, without taking as much time. Plus code review has an inherent context switch (for the reviewer) that is even worse during a crunch time.
Pair programming is not used at all at Google, mostly for all the bad reasons cited in the article. And also because code reviews really do work (admittedly, Google has a fantastic infrastructure to support it).
Earlier quoted context omitted.
In this case, though, the pair was limited to the abilities of the weaker member.
As it should be; a weaker member is like a failed raid drive rebuilding until it's up to speed with the team. You expect things to go slower until he's up to speed. If speed is necessary, the senior programmer can always drive and let the other guy watch and ask questions, or explain as he goes along.