2 ms·

Please read the article all the way through before commenting. Your other points are already addressed.

adrianomartins 5y ago
I think davedx read the article, davedx even copy/pasted/quoted it, and I totally agree, the author is being overly simplistic in the analysis made. And on the other hand, somehow the author of the article passes asynchronous code reviews as good thing. I mean, that is THE problem that pair/mob programming is solving, imho.
- kstenerud 5y ago
  I don't understand... what is wrong with asynchronous code reviews? From my POV code reviews are the solution to the pair programming problem.
  - nijave 5y ago
    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 something else while waiting on the review" but then you introduce new problems - more context switches - the longer code goes unmerged, the more conflicts can build up - unmerged code can block other things
    - kstenerud 5y ago
      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.
berdario 5y ago
Except that the points aren't really addressed. The article argues in favor of "code reviews, design reviews, and general documentation" but it totally avoids discussing the merits and disadvantages of them. It's not only pair programming that has pro and cons, and so using a different process (or more likely, a mix of different processes) always implies a tradeoff.
xenocratus 5y ago
I assume you mean this part: > While pair programming might achieve some goals as a pedagogical tool, there are more time and cost efficient ways to share knowledge between team members. It's a very hand-wavey dismissal - "yeah, that doesn't work... NEXT!". I've enjoyed both sides of the learning process in pair programming and implying that documentation can cover everything that can be learned like that is, in my experience at least, laughable. It's not just about code, it's about the whole process, including other tools you might use, where and how to find things, etc. Engineers have different backgrounds that might've taught them different ways of approaching certain tasks. Some of those might stick
- kstenerud 5y ago
  Sure, he's not going into extreme detail, but then again I doubt that's the point of the post. I found myself nodding in agreement as I read along, but that's probably because I've been in the trenches so long. I've done it both ways and I've never seen pair programming as having any significant advantages, but rather having drawbacks in most (though not all) situations.

I think davedx read the article, davedx even copy/pasted/quoted it, and I totally agree, the author is being overly simplistic in the analysis made. And on the other hand, somehow the author of the article passes asynchronous code reviews as good thing. I mean, that is THE problem that pair/mob programming is solving, imho.

kstenerud 5y ago
I don't understand... what is wrong with asynchronous code reviews? From my POV code reviews are the solution to the pair programming problem.
- nijave 5y ago
  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 something else while waiting on the review" but then you introduce new problems - more context switches - the longer code goes unmerged, the more conflicts can build up - unmerged code can block other things
  - kstenerud 5y ago
    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.

berdario 5y ago

Except that the points aren't really addressed. The article argues in favor of "code reviews, design reviews, and general documentation" but it totally avoids discussing the merits and disadvantages of them. It's not only pair programming that has pro and cons, and so using a different process (or more likely, a mix of different processes) always implies a tradeoff.

xenocratus 5y ago

I assume you mean this part: > While pair programming might achieve some goals as a pedagogical tool, there are more time and cost efficient ways to share knowledge between team members. It's a very hand-wavey dismissal - "yeah, that doesn't work... NEXT!". I've enjoyed both sides of the learning process in pair programming and implying that documentation can cover everything that can be learned like that is, in my experience at least, laughable. It's not just about code, it's about the whole process, including other tools you might use, where and how to find things, etc. Engineers have different backgrounds that might've taught them different ways of approaching certain tasks. Some of those might stick

kstenerud 5y ago
Sure, he's not going into extreme detail, but then again I doubt that's the point of the post. I found myself nodding in agreement as I read along, but that's probably because I've been in the trenches so long. I've done it both ways and I've never seen pair programming as having any significant advantages, but rather having drawbacks in most (though not all) situations.