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

Against Pair Programming

matt-rickard.com

Post reply on HN
Print view View original

161–170 of 180 posts

Re: Against Pair Programming

#161

Post by travisjungroth »

watwut wrote: post #116
toqy wrote: post #92

Earlier quoted context omitted.

> That analogy is just yet another way how to shut up people who dont like the process. In that case explaining why you like anything is a way to shut people up who don't

> In that case explaining why you like anything is a way to shut people up who don't No. It is just that specifically agile has a way to responding to people who dont like something with very very handwavy explanations that feel good, but dont really mean anything. Explaining why you personally like something is entirely different kind of communication. Explaining why you think something works well is also different.…

> Why rally racing and not any of the other races where competitors are alone? Why not soccer team for that matter? That seems closer to development then any vehicle racing anyway.

There seems to be two directions of analogies here. One is arguing from subject to analog. “Programming is like rally car driving so we should act like they do.” Pretty crummy argument. I’d have no answer to your “why rally car?” question.

The other direction is explaining from subject to analog. “Strong-style pair programming is like rally car driving.” There’s much less of a claim here. I’m just saying they have enough shared attributes that I can map how they’re similar and you may find that useful for understanding. So why rally cars? Because that’s the context that has the most similar method as the one I’m talking about (not that it’s the most similar context).

In the latter case, the claim of fitness is separate from the analogy. “This method is useful. It’s like one rally car drivers use”. There’s no “because” in there.

Re: Against Pair Programming

#162

Post by rr808 »

usefulcat wrote: post #157
rr808 wrote: post #41

Earlier quoted context omitted.

Nice. How do you sustain this for 8 hours a day though? After 45 minutes my brain starts to sag.

At one time in my career I pair programmed pretty much all day, every day for the better part of four years, with the same person. We started with an existing codebase, but even from the start most of the work we did was on new features. It is intense, but--at least in my experience--it was also very productive. You basically can't/don't ever slack off. And I learned a lot from the other developer (mainly about vario…

> You basically can't/don't ever slack off.

I think this is the best part of PP, its a great way to avoid procrastination.

Re: Against Pair Programming

#164

Post by taylodl »

I've been pair programming since the 80's - long before the practice had a name. Bottom line - pair programming creates a higher-quality result in less time. I can't state it any more succinctly than that.

The higher-quality result bit is nothing to sneer at, either. Two minds are better than one. That means it's a better implementation having fewer bugs and fewer edge case surprises. These are things that all drive up software development costs.

You know what's costly? Shipping buggy software. Especially back in the day when you had to distribute software via physical media that had to be shipped to the user. Things get even more complicated when the software is being used in a mission-critical process needing to run 24x7. Outage windows can be difficult to find.

So sure, if you're creating software nobody really cares about because it really isn't critical to anything then I guess pair programming might be overkill. But who wants to work on such software?

Re: Against Pair Programming

#165

Post by stjohnswarts »

tweakimp wrote: post #17

>>> Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense. Not at all. Two programmers working on the same project at the same time is already slower than one programmer working twice as long because these two have to communicate. And during pair programming, the communication is s…

I consider that brainstorming and working with a team mate, not pair programming. As a daily thing it's ridiculous and only for people who are exceptionally friendly and need a lot of human interaction. Give me a problem, a laptop, and some space and I'm all set. I agree with brainstorming during the design phase(s) of a project though, lots of good ideas come out and there is some synergy you can have that will never happen over zoom or email.

Re: Against Pair Programming

#166

Post by calsy »

commandlinefan wrote: post #105
calsy wrote: post #95

Pair programming stinks, always has always will. Its another mindless initiative managers come up with because some person in the organisation who subscribes to the Agile cult (there is always one) wont stop going on about it. Like most things Agile, it treats the developer as a child who cant be trusted to get things done. It's grade school where teacher tells you it's time for 'pair programming', yeahhhh. Usually i…

> most things Agile, it treats the developer as a child Hey, don't blame "agile" for that - blame the bastardization of what managers who live to treat other people as children (or more likely as "subjects") have turned a decent concept into.

Agile is manager centric analytics tool that attempts to measure the ‘intangibles’ of development. This is done through rigid conformity to process.

Excessive deliberation over design and breaking down of tasks gives the managers the info they need for the ‘higher up’s’ and the ability to better micro manager there subordinates.

It’s brilliantly sold as a way to assist development, while focusing on the concerns of management.

Re: Against Pair Programming

#167

Post by kstenerud »

nijave wrote: post #160
kstenerud wrote: post #148

Earlier quoted context omitted.

I don't understand... what is wrong with asynchronous code reviews? From my POV code reviews are the solution to the pair programming problem.

Async code reviews are slow. A code review is about getting people to agree on the code being reviewed (ideally using a set of objective guidelines). Instead of having a review done in an hour, for instance, it can easily stretch into days of back and forth to reach a consensus. Throw in a third person and now you have 3 people trying to asynchronously synchronize on a desired outcome. You could say "ok, I'll just do…

Wow... If this has been your experience then you've had rotten luck. I've never experienced this in 25 years developing professionally.

On a typical code review, a reviewer takes about 10-15 minutes tops to review the code in a PR. 75% of the time the code just gets approved. Otherwise it's usually a few minor points that are 2 minute fixes, and rarely it becomes more involved because the person was unaware of something important (so a 20-30 minute fix, or perhaps a meeting to discuss the issue and come to a concensus if nobody's really sure how to deal with it).

PR code chunks are kept small so that things are easy to review, and easy to switch back to if there's a problem. Generally there's 0-1 cycles per review. If we're working on something big, we make an integration branch for that feature and then merge the changes in multiple small PRs again, so that only the integration branch itself needs to be kept up to date with mainline. Blockages due to unmerged code are unheard of (at least I've never experienced it).

I do on average 3-4 code reviews per day, and this has been my experience for my whole career (aside from two places that did pair programming instead) spanning many companies from startups to multinationals.

Re: Against Pair Programming

#169

Post by SideburnsOfDoom »

sascha_sl wrote: post #152
SideburnsOfDoom wrote: post #143

Earlier quoted context omitted.

> Asynchronous workflows should be the default. Interruptions are almost universally bad, What's great, though, about getting some work ready, creating the PR; and then waiting .. Minutes? Hours? ... days? who can tell? For a response. if you're wanting "productive", that isn't it.

But you're breaking someone else's productive time. The way around this is (1) having enough work prepared that you can start on something else and (2) cutting your PRs well enough for them to be entire (sub-)tasks. And if you can't, maybe you need to cut smaller tasks.

> But you're breaking someone else's productive time

Yes, the system's productivity is not about maximising the uninterrupted productivity of person A, or of person B either.

Sending a whole pile-up of PRs isn't a great solution either.

Re: Against Pair Programming

#170

Post by calsy »

rr808 wrote: post #162
usefulcat wrote: post #157

Earlier quoted context omitted.

At one time in my career I pair programmed pretty much all day, every day for the better part of four years, with the same person. We started with an existing codebase, but even from the start most of the work we did was on new features. It is intense, but--at least in my experience--it was also very productive. You basically can't/don't ever slack off. And I learned a lot from the other developer (mainly about vario…

> You basically can't/don't ever slack off. I think this is the best part of PP, its a great way to avoid procrastination.

That’s what happens when someone looks over your shoulder.
Post reply on HN