Slashdot Mirror

← Back to Stories (view on slashdot.org)

Code Reviews vs. Pair Programming (mavenhive.in)

Posted by timothy on from the quit-crowding-me dept.

An anonymous reader writes: I've spent nine years working in teams which religiously follow pair programming. I'm used to working that way and appreciate the benefits it brings. We didn't have the luxury of pair programming all the time in my last project. This required us to do code reviews to ensure the quality of the code we delivered. This post is an attempt to consolidate the upsides and downsides of doing code reviews instead of pair programming in my three months of experience.

7 of 186 comments (clear)

  1. Nine years of pair programming? by 110010001000 · · Score: 4, Insightful

    You have gone through nine years of pair programming and haven't shot yourself? The idea of pair programming itself is insane. I didn't know anyone actually did it.

    1. Re:Nine years of pair programming? by gstoddart · · Score: 4, Insightful

      Nine freakin' years, the mind boggles.

      On occasion I've sat with someone as we've worked through a complex thing and a second set of eyes was useful, and it wasn't terrible. I've definitely done code reviews, and it can contribute to better code.

      But 9 years doing pair programming? Good lord, my first though is "you're doing it wrong".

      If I wanted to spend 9 damned years helping a junior anybody build their confidence and skillset in anything ... I'd have gone into teaching.

      This just seems like you get half productivity all of the time, instead of two people pushing out code on different things, and then reviewing/debugging it later.

      Do we ever see "pair accounting" or "pair plumbing"? To do this all the time seems wasteful, and ridiculous. Nine years of it seems like madness.

      --
      Lost at C:>. Found at C.
    2. Re:Nine years of pair programming? by UnknownSoldier · · Score: 3, Insightful

      1. Find a better teammate then. Tossing the baby out with the bathwater just because it didn't work for you is irrational.

      2. When both of you are "in mental sync" it works great ! When not, it is a waste of time, for both of you. :-/

      3. Did you forget Brook's Law? There is no silver bullet Why? Because it depends on _context_.

    3. Re:Nine years of pair programming? by JoeMerchant · · Score: 3, Insightful

      If you've got a "RockStar" - odds are that noone else can follow his work, so there's benefit in pairing there to get extended life and maintainability out of his productivity, enabling others to better maintain his(/her) code and freeing up your superstar to continue breaking new ground instead of getting bogged down in maintenance of the old stuff.

      If your "RockStar" does produce code that is readable and maintainable by mere mortals, then you definitely want to pair them up with the plebes so they learn how to do that, because most programmers can't.

      If spending 4 to 8 hours a week "paired up" with colleagues is too much for your precious flower to handle, watch out for exploding egos and horrible personality clashes.

  2. There is a third option by Anonymous Coward · · Score: 3, Insightful

    ...and it is rather simple.

    Design > Discuss > Refine > Implement > Run code analysis

    This can be done in any workflow and in pairs. You don't gobble up the time of two team members but you still get to discuss the most important part of the implementation. You can even do a light-weight review afterwards with a check list of practices to focus on.

  3. Pair programming is like tandem bicycling by Tony+Isaac · · Score: 4, Insightful

    There might be times when it's nice to have the second person helping pedal up a long hill. But you're certainly not going to double your speed or your stamina with two people on one bicycle.

    Pair programming is like that. There are specific situations where it's useful, especially when you're dealing with a tricky algorithm or intricate business requirements. But much of the time, the second person is just dead weight.

  4. Software development has become idiotic... by javabandit · · Score: 4, Insightful

    ... I swear. Lean, SCRUM, XP, Agile, Waterfall, Kanban, Scrumban, TDD, BDD, Pair Programming, Code Review, User Stories... etc... etc... etc.

    How about just be a responsible craftsman, understand the customer's requirements and needs, and implement your solution responsibly and with integrity? Whatever that means. If you need to pull someone in, then do it. If you don't, then don't. Christ, how complicated is this? It's one thing to be a junior developer and having to learn things. Fine. But an experienced software developer should not require constant canoodling to get their job done responsibly, with integrity, and with good quality. Is it really that hard?

    I'm from a pretty old-school programming upbringing -- back when you were a "Programmer" or "Analyst" or "Programmer/Analyst". I'll tell you in those days... if a programmer demanded this kind of ridiculous hand-holding, canoodling, and process-implementation to get their job done... they would be fired. Plain and simple. This industry has become awash with process and tool zealots... while knowing the customer's needs be damned.