Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Where Pair Programming Fails for Me

tersesystems.com

Post reply on HN
Print view View original

21–30 of 41 posts

Re: Where Pair Programming Fails for Me

#21

Post by metageek »

gnaritas wrote: post #4
wccrawford wrote: post #3

I got to the point where the other person started typing when it wasn't their turn. First, pair programming has to be between near-equals, or it just doesn't work. If one person knows a lot more than the other, most of the time is spent in training. Second, if the other person just starts typing, it isn't really pair programming. It's what we call 'peer programming' where you peer over someone's shoulder and they do…

> 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.

Re: Where Pair Programming Fails for Me

#24

Post by will_sargent »

joevandyk wrote: post #14

I think the author is conflating Pair Programming with other concepts. There are no high notes, no thought out design. There’s only the design that could have tests written for it, in the time you had to write the tests. The classes look reasonable at first glance, and the methods are seemingly bug free. But the cracks are there, if you know where to look. ... Eventually, I realized that many of my partners had never…

> What on earth does any of that have to do with Pair Programming?

I'm the OP.

What I'm describing is my experience Pair Programming in one organization, and why it didn't work for me. To tell the story, I needed to provide the context and the background to say why it didn't work for me. They're distinct issues, but the only way we could relate to those issues and work through them was through the lens of pair programming.

Keep in mind that I'm not trying to say that Pair Programming is a flawed practice in principle, or even that their approach was flawed _in practice_ for the company -- there are other metrics besides code quality that a startup needs to consider if it's going to survive, and sometimes "good enough" code is good enough.

I'm well aware that pair programming works very well for some people, and that my experience may not be typical. However, just because my experience wasn't typical doesn't mean it didn't happen.

Re: Where Pair Programming Fails for Me

#25

Post by harringf »

blatherard wrote: post #13

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…

> "let's take a walk" and then talk through design problems.

That is the MOST important part and yet every single training fails t mention this.

Re: Where Pair Programming Fails for Me

#26

Post by sofuture »

bkz wrote: post #18

My view is that pair-programming is a tool which only really works for stuff dealing with tactical decision making, logic/fact checking, teaching or debugging. Higher level abstract stuff which involves creativity (design) or strategic decisions won't work because there is no process for these activities. You can't synchronize (communicate) where you are on your way to the "eureka" moment. Discussing with others cert…

I didn't even know people pair programmed full-time. It sounds... awful.

My idea of pair programming is a ~monthly "Hey coworker, you want to do sitdown this afternoon and figure out (in code) this bug/feature/design?"

Doing it fulltime sounds inflexible and impractical.

Re: Where Pair Programming Fails for Me

#27

Post by sandGorgon »

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.

Re: Where Pair Programming Fails for Me

#28

Post by palehose »

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 do not have experience working on an "agile" team doing every day pair programming. There are a lot of job descriptions that back this issue up.

I learned Ruby on Rails on my own and have successfully developed and deployed two significant applications during my spare time using Ruby on Rails in the last 3 years. The applications I've written are not open source and they are not public access sites, and until I do get something written within the public facing / open source realm, I am convinced that I probably won't ever get considered for a full time rails job.

I've mostly just about given up on ever expecting to get hired by a company that uses Ruby on Rails. It is all total bullshit in my opinion. I will continue to use Ruby on Rails on my own and ignore Pair Programming because I see Pair Programming as a form of micromanagement and not an opportunity for programming productivity.

I have plenty of experience working with other software developers on the same piece of code, in front of the same terminal window, for two or three hours at a time - always initiated by myself or the other developer, not prescribed by management. The fact that I don't do it every day is irrelevant in my opinion.

Re: Where Pair Programming Fails for Me

#29

Post by billmcneale »

This matches my experience as well.

Like most things advocated by XP people, pair programming is simply soul crushing and meant to replace skill and experience ("I know it's not the simplest thing that could possibly work but my experience tells me we'll be needing this later") with mindless repetition.

Very much like religion.

Thanks, but no thanks.

Re: Where Pair Programming Fails for Me

#30

Post by billmcneale »

sandGorgon wrote: post #27

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.

Post reply on HN