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.

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

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