16

In an extreme programming project, programmers do pair programming most of the time.

As these pairs also rotate, that is, you pair program with different people, and there is a sense of collective ownership, source code is being frequently reviewed and updated.

Being so, is there a need for code reviews? I mean, stop programming and actually just do code reviews.

Improve this question
3
  • 3
    Pair programming is only a tenant of XP. There are many other agile methodologies that do not follow XP. There is nothing in Manifesto for Agile Software Development nor Principles behind the Agile Manifesto that mentions pair programming. There's also nothing about code reviews either. Its important not to assume that all agile is extreme.
    – user40980
    Dec 4, 2014 at 21:31
  • Let me rephrase my question to include only XP then.
    – Eduardo Copat
    Dec 4, 2014 at 21:33
  • Is there a reason why you wouldn't try it and make sure you set some criteria to stop? If the team is comfortable with the code getting checked-in, that should be a good enough reason.
    – JeffO
    Dec 5, 2014 at 21:01

1 Answer 1

Reset to default
15

One of the key resources for Extreme Programming is that of Ward's Wiki aka Portland Pattern Repository aka C2.com. This is where a number of people hashed out various methodologies and documented them as they used them.

Within this wiki, there is a page: Extreme Programming Code Reviews that has a number of contributors to it, including Ron Jeffries and Kent Beck.

To this, they said:

Code reviews are considered important by many large-process gurus. They are intended to ensure conformance to standards, and more importantly, intended to ensure that the code is clear, efficient, works, and has QWAN. They also intended to help disseminate knowledge about the code to the rest of the team.

ExtremeProgramming requires that all development is done by two engineers working together. The code is actually reviewed on the fly, to quite a great degree. This ensures that more than one person has intimate knowledge of the code at all times.

ExtremeProgramming requires that all objects have UnitTests. These ensure that the object works, and continues to work as modified.

Some languages are reflective. In such languages, UnitTests can check directly for important standards conformance. (e.g. objects must implement both #= and #hash, or neither.)

ExtremeProgramming practices CollectiveCodeOwnership, which means that objects needing attention will be browsed by many developers. This tends to bring pressure to bear on those producing code that doesn't conform to standards. Visiting developers are encouraged/expected to bring code into conformance when they find deviations. This also ensures that knowledge of code is disseminated beyond the initial pair of programmers that created it.

Therefore, ExtremeProgramming projects do not require explicit reviews. Drop them from your methodology.

There is also quite a bit more discussion on the topic there from others.

The key points though being that with the combination of tests, collaborative ownership and pair programming these things resolve the goals that a code review is typically supposed to do such as:

  • Disperse the knowledge of what is being done
  • A second (or more) set of eyeballs on the code to make sure it is following standards
  • Verify correct functioning of the code

These are being done continuously through pair programming and automated testing in Extreme Programming and thus an explicit Fagan inspection is unnecessary.

Related reading:

Improve this answer
4
  • 4
    I argued in another q&a that code review is an unnecessary waste (in the Lean sense of the word) and that pair programming should be the preferred method of providing all the benefits that a code review would provide. Needless to say, people took offense to my argument because I hadn't backed it up with THE VOICE OF AUTHORITY (TM) like you have. For a group of people who deal with logic day in day out, we are an illogical bunch.
    – Michael Brown
    Dec 4, 2014 at 22:15
  • 6
    The risk of doing pair programming without additional code reviews is that both programmers are heavily involved at the moment of writing and they may write code that seems completely clear and logical at the time, but less so when seen again after a few days. How big and/or acceptable that risk is depends on your organization.
    – Bart van Ingen Schenau
    Dec 5, 2014 at 7:42
  • @MikeBrown you could equally argue that Pair Programming is an unnecessary waste and that code review should etc etc.
    – Alex
    Dec 5, 2014 at 14:58
  • See what I meant by WASTE was the "Lean" definition of the word. Think of the typical assembly line process. The idea is to get the car down the line as quickly as possible and quality checks are done after the fact (code review). Lean principles espouse taking a little more time and effort to build quality in (pair programming) so the post check becomes unnecessary.
    – Michael Brown
    Dec 5, 2014 at 15:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.