1. 1
  1.  

  2. 3

    Bug fixes will need design review because you need to make sure your previous design is still valid.

    One of the most frustrating parts of “legacy” code is that you spend all this time reading design documents, only to find a litany of bugs that combined undermine the main goals of your design.

    Maybe I’m referring to something more akin to root cause analysis..

    1. 1

      This is spot on for why I dislike code reviews (though they’re better than none at all). I was waiting for the punch line of “pair programming”, but it never happened. We got “design reviews”, which are certainly under used in my experience, but if we’re afraid to throw all that code away, or it takes too much time (a week on a code review?!?), then why not skip all that and just pair program, at least for the stuff that you’d normally be doing deep-dive code reviews?

      1. 3

        What happens when a third person wants to learn about this code? Pair programming always seems as a super undocumented, tribe-y way of handling design/code review.

        Is there a good pattern for pair programming to document their work?

        1. 1

          In my experience, when code is written by a pair, you end up with more and better tests that make it easier to understand the code, as well as more readable code overall. I’d personally rather have well organized tests than documentation that goes out of date without anyone even realizing.

          Pair programming always seems as a super undocumented, tribe-y way of handling design/code review.

          Has this been your experience? I’ve sometimes had bad pairing sessions, but I’m not sure why they’d be “undocumented” or “tribe-y” (I’m not quite sure what that even means?). Also, pairing doesn’t replace design review for me, I think that’s still important.