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.

34 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 Anonymous Coward · · Score: 5, Interesting

      (Going anonymous)

      You are likely running this through a cultural filter.

      The Indian teams that I have worked with are a lot more about huddling around a computer working things out, than the typical US approach of developer with headphones collaborating a couple of times a day. Different cultures do things differently.

      Looking at *real* salary information between two geos (Bangalore and Silicon Valley) comes out roughly as follows.

            Architect level 2:1.
            Junior level 5:1

      You can have pair programming for junior staff and still have a very strong cost advantage in India. That cost advantage plus a cultural tendency would make pair programming fairly easy to apply.

      Not making any comment about the quality of code or quality of engineers on either side of the pacific...

    2. Re:Nine years of pair programming? by 110010001000 · · Score: 2

      I think you are right after reading the article it seems like it is a typical outsourced development environment (which sounds hellish). Carry on!

    3. 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.
    4. Re:Nine years of pair programming? by 110010001000 · · Score: 4, Funny

      It definitely saves on heating costs if they all share a blanket.

    5. Re:Nine years of pair programming? by alvinrod · · Score: 4, Interesting

      Even the early academic studies (PDF warning) of the effectiveness of pair programming found that you didn't quite get as much out of a pair team as two individuals working independently. However the code quality is generally a lot better in terms of correctness or readability.

      If you have a few individuals who are new to an organization or becoming acclimated to a new project they've not worked on previously, pairing can make some sense. On the other hand if you've got a rock-star developer that's head-and-shoulders above the rest, it's probably not worthwhile to pair them with another person.

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

    7. Re:Nine years of pair programming? by cob666 · · Score: 2

      I was a long term contractor at a rather large international company that recently outsourced all their IT, which included application development, to an India based company.

      I've had to deal with the client and the new support company several times over the last year and I agree that the mindset is completely different. They tend to work in teams of 2 or 3 with only one person doing any actual work at any given time. I'd love to say that the this results in either increased productivity or a better code base but I haven't seen any examples of that.

      --
      Do what thou wilt shall be the whole of the Law - Aleister Crowley
    8. Re:Nine years of pair programming? by fahrbot-bot · · Score: 2

      Does having 5 people huddled around a computer increase productivity or increase slippage?

      I think you misunderstand the meaning of the word "pair". Unless you're thinking two pairs and a hot-spare.

      --
      It must have been something you assimilated. . . .
    9. Re:Nine years of pair programming? by eulernet · · Score: 4, Interesting

      This is nothing new.

      The effort of every individual in a group of people has been measured by Ringelmann in 1914, for army's purposes.
      Here is the original article: http://gallica.bnf.fr/ark:/121...

      And the results are (number of people => measured effort)
      1 => 100%
      2 => 93%
      3 => 85%
      4 => 77%
      5 => 70%
      6 => 63%
      7 => 56%
      8 => 49%

      This is called "Ringelmann effect" or more recently "social loafing".
      As you can see, 8 people produce the same amount of effort than 4 individuals.

    10. Re:Nine years of pair programming? by avandesande · · Score: 2

      Actually I have learned quite a bit about efficiently running IDEs, debuggers and troubleshooting techniques from pair programming. Coding, not so much- I can pick that up just looking at someone else's code.

      --
      love is just extroverted narcissism
    11. 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.

    12. Re:Nine years of pair programming? by ILongForDarkness · · Score: 3, Interesting

      You're maybe a better coder than I or people I've worked with. I find the majority of my time isn't spent "writing" it is spent finding the stupid little errors like a != that should be an == or forgetting to do a null check etc. I type about 60wpm but commit maybe 100 loc of production ready code a day. The bottleneck isn't writing. It isn't thinking either: my list of "good ideas" and simple should do refactors grows faster than I can do them. I'm limited by my ability to find and debug stupid mistakes in code, whether mine or falsely blamed on me by CI.

      Pair programming could help with that I think (haven't done it for more than an hour at a time so don't feel confident stating an opinion one way or another0 because my tendencies towards stupid mistakes might not be the same as my pair. A quick: wait that is dumb every 10 min could save me hours of debugging. My guess though is that you should change pairs frequently so you don't start falling into the same mistakes as your partner or end up with 2 people that are the only guys that can review each others work because they are the only ones that have worked on X for a year.

  2. Clever PHBs... by __aaclcg7560 · · Score: 2

    Is that the new name for doubling up in the cubes to squeeze the most performance by square feet?

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

    1. Re:There is a third option by mtippett · · Score: 2

      +1

      A common issue with code reviews is that the engineer making the change presents the completed implementation and the design *at the same time*. The collaboration early on to ensure a good design or theory of operation really helps cut down on the pain of code reviews.

  4. Watching someone code drives me insane by sanosuke001 · · Score: 5, Interesting

    Watching someone else code is the most maddening thing. They always seem to take the long way of doing something; use the mouse and doing eight clicks where a keyboard shortcut would do, etc. I do my best to not watch people code when I'm trying to help them. I would have killed someone years ago if I did that full time.

    --
    -SaNo
    1. Re:Watching someone code drives me insane by gstoddart · · Score: 3, Interesting

      There's no way in hell I could function in that close proximity to ANYBODY for 9 years. Not even my wife, and I kinda mostly like her.

      I don't wish to spend my day with someone right up along side me.

      My experience with it is 1-2 hours is the absolute upper bound, and then it's going to turn into two kids in the back seat of a car on a long ride.

      What idiot thinks doing this all day every day would increase productivity?? That isn't a team mate, it's a fucking cell mate.

      --
      Lost at C:>. Found at C.
    2. Re:Watching someone code drives me insane by Kjella · · Score: 2

      Watching someone else code is the most maddening thing. They always seem to take the long way of doing something; use the mouse and doing eight clicks where a keyboard shortcut would do, etc. I do my best to not watch people code when I'm trying to help them. I would have killed someone years ago if I did that full time.

      Same here, it's one thing to discuss structure, interfaces and workflow but pair programming is two people painting a house with one brush. Even a training session with me typically starts with show and tell then handing off simple assignments to work on your own pace. You have the documentation, compiler, you can run it on some test data and I'm often going to outline a solution in the beginning. Even if we're two experienced developers working on it I'd rather play tag team or good developer/bad developer trying to improve or make the code break.

      Personally I find my mental span - that is to say, roughly how much of the solution I can have planned out in my head at once is much bigger if I don't have to chit-chat and explain every little thing. And very often that's how the solutions really come together and work, instead of having bits and pieces that looked okay on their own but just mismatch when put together. Because very often that leads to kludges, that lead to messes, that lead to "there be dragons", that lead to dirty fixes, that turns into an unmaintainable mess. Without falling into the architectual perfection trap, it's amazing how some good design choices keeps the system consistent and much easier to understand.

      --
      Live today, because you never know what tomorrow brings
  5. Code Review Pair Programming by i_ate_god · · Score: 4, Interesting

    A proper peer review process is far superior. Review your plan with your teammates. If you're working with components that others work on, make sure they are part of the plan review. Once all questions are answered, put your headphones on and go forth and code. Rely on unit tests to catch the obvious problems, rely on integration tests to catch less than obvious problems, rely on QA to catch what your integration tests miss. Use linting, static code analysis, and other tools like Sonarqube to identify potential problems within your code that may not manifest themselves under day to day usage. Voila...

    Is it perfect? Of course not. Will your software be 100% bug free? Of course not. It also doesn't solve problems related to lack of intelligence or experience amongst your teammates, and it doesn't solve problems related to lack of foresight from management who impose impossible deadlines or who close deals with customers that include features which don't exist. But the team will still be more productive than if they had to share computers and work in pairs. Programmers need focus and pair programming will ruin any focus you could have.

    --
    I'm god, but it's a bit of a drag really...
  6. Collaboration by milgner · · Score: 3, Informative

    This happens in pair programming when the entire team is sitting in one place and conversations can be overheard

    I wouldn't know a better way to destroy productivity than having people pair programming in a public space. How is anyone supposed to concentrate on their work or their coding partner while listening to the conversations of everyone else in the room at the same time?

  7. Not big on pair programming but by Copid · · Score: 2

    ...pair debugging can be great. Two people looking at the same code and same test output at the same time can go back and forth designing tests and interpreting results really effectively, especially if the bug is at the intersection of two modules that you're reach responsible for. Of course, you don't spend all day every day debugging or something has gone very wrong wrong.

    --
    An interesting anagram of "BANACH TARSKI" is "BANACH TARSKI BANACH TARSKI"
  8. 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.

  9. Team Reviews are far superior by Ckwop · · Score: 4, Interesting

    In our organisation, we have teams of six people that work together on their sprint. QA staff are included in this team.

    On major features, the team code reviews the feature together in a special session. Roles are assigned. The author is present, a reader (who is not the author) reads the code. There is an arbitrator who decides whether a raised issue gets fixed. This arbitrator role is rotated through the team on an inspection by inspection basis. Finally, there is a time keeper role who moves the conversation to a decision if one topic is debated for more than three minutes.

    This process typically finds a humongous number of issues. It takes us about 4 hours of applied effort to discover a bug in pure functional testing. This process discovers bugs at a rate of 1.25 bugs per man hour of applied effort. So if you have five people in a room for one hour, you have applied 5 man hours. You'd expect to find 6-7 bugs. If you include all the stylistic coding standards bugs, this is typically 10-15 bugs per hour.

    So while on the surface it looks expensive to have all those people in a room talking. The net result is that it tends to accelerate delivery because so many issues are removed from the software. Better still, the review occurs before functional testing begins. This means the QA staff on the team can direct their testing at the areas highlighted by the inspection process. This further improves quality

    It's true that about 50% of the ossies are stylistic issues. But usually we get 1 or 2 bugs per session that present a serious malfunction in the program. The rest could be problems under some circumstances or minor faults.

    Team reviews are vastly, vastly superior to pair-programming. There really is no contest.

    1. Re:Team Reviews are far superior by 110010001000 · · Score: 2

      You sound like a bean counter, and your organisation sounds like it is hell to work in. 1.25 bugs per man hour? Christ.

    2. Re:Team Reviews are far superior by Ckwop · · Score: 3, Interesting

      You sound like a bean counter, and your organisation sounds like it is hell to work in. 1.25 bugs per man hour? Christ.

      Well I'm the head of development at our place so I inhabit both worlds. Businesses like to measure return on investment. By being able to speak that language, I can generally frame activities developers naturally want to do in those terms. This leads to developers getting more of what they want.

      You know what developers really, really, really hate? Having to work with technical debt and having no process to remove that technical debt because the program is now "working".

      The best way around technical debt is not to put it in to the program in the first place. This process does a sterling job at that. So our developers are generally a pretty happy bunch.

    3. Re:Team Reviews are far superior by Ckwop · · Score: 2

      No offense meant, honestly, but your place sounds miserable to work at. It's not the process, but the ridiculous level of formalization and standardization.

      Code inspections work best when they're formal with clearly defined roles and clear reporting steps. There have been large scale studies done that confirm this. The research fed in to the development of the Cleanroom methodology pioneered at IBM.

      The less formal the structure, the less well it works.

      One of my big bugbears with software development as a craft is our failure to really learn from experience. There were lots of studies done on the craft from decades ago that cleanly establish these basic principals. We choose to ignore them because developers feel they know better than published research.

      The truth is that people suck at writing software. Even the very best developers in an organisation are not as a good a team of lower quality people that inspects their own output. Teams > individuals.

      Honestly, it isn't as corporate as it first appears. Once the roles are defined, the work turns to inspecting the source. It takes a few seconds to cover off that part of the meeting and from there the real work begins.

      There are other benefits

      One is that everyone has read everybody's source. There's none of this "Only Bill knows that piece of code." The whole team knows the code very thoroughly.

      Another is that relatively junior people end producing code just as solid as person with 25 years experience. They end up learning a lot on the way. Do not estimate the tremendous power of that.

      My teams enjoy the process and they certainly enjoy not getting as many bugs coming back to bite them in the future when the feature is out in production. Once they're done, they tend to be done and are free to move on to the next feature.

      The benefits of having a cleaner code base, fewer issues and more accurate delivery times has a huge affect on morale.

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

  11. Re:Count me out by mwvdlee · · Score: 3, Funny

    You prefer peer review or test-driven?

    --
    Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
  12. Technical debt by Locke2005 · · Score: 2

    Case in point: I'm maintaining HP printer firmware. Do you have any idea how resistant they are to fixing bad design decisions made long ago by people that no longer work here? The code is the result of decades of band-aid fixes... and it shows.

    --
    I've abandoned my search for truth; now I'm just looking for some useful delusions.
  13. Re:Count me out by Hognoxious · · Score: 2

    If you haven't been to the range for a day or two than yellowish is OK.

    You should see a doctor.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  14. Re:Count me out by mwvdlee · · Score: 2

    I guess if you crank out a 100 per hour, all green is somewhat to be expected.

    --
    Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
  15. Context Context Context by gfdgfdwrg · · Score: 3, Interesting

    Pair programming when creating new features: FAIL. Pair programming with the guy who wrote the original code when you find bugs: EPIC WIN

  16. Reviews always required by Baki · · Score: 2

    Even if you would think pair programming makes sense (I don't, but it might be cultural as some have claimed), they cannot replace code reviews.

    Both "pair programmers" are following the same thought process and may fall in the same trap.

    A fresh look, by someone who wasn't involved in coding is always required.