Traditional code reviews are not much fun, particularly for the author.  They are very valuable, but can easily devolve into a bashing session.  Using the Charrette Protocol could be a more effective alternative that leaves the author in control and makes it more fun for everyone involved.  The charrette is also more in-line with Agile practices.

In a one-pager, Kathy Juarez of Piner High School, Santa Rosa, California proposes adopting the Charrette Protocol for education, "to get feedback on a work in progress when a teacher, student, or group is ‘stuck’."  Kathy credits Carol Coe at Puyallup High School (WA) for describing the protocol.

As I read it, it struck me that this protocol would fit quite well in software development as a complement to code reviews.

I particularly like the idea that the charrette empowers the person asking for it which is quite the reverse of traditional code reviews.

Code Reviews

Traditional code reviews are a supervisory function, a "grading" event.  They are not much fun for participants, and, in particular,  they are not fun for the author whose code is being reviewed because they can easily devolve into a bashing session.

There are two types of traditional code reviews: Gatekeeper and Episodic code reviews.  In Gatekeeper reviews, gatekeepers review new code before it can be checked into the source base.  In some cases, one or a few developers are assigned permanently to this task; in other cases, any developer can play the role of reviewer.  But one way or the other, somebody has to review the code before it is checked-in.  This is a good practice, key to successful continuous integration and orthogonal to charrette.  (Charrettes are also orthogonal to techniques such as Pair Programming that embody a certain level of review.)

In Episodic reviews, a developer presents his code to a team of his peers for the purpose of having the team critique the code, make suggestions for improvements, find gaps in the design, find coding bugs, etc.  Although nothing prevents an author to call for a review, it is rarely done voluntarily; most often, reviews are imposed on developers as part of the development process.  Even in cultures that welcome code reviews and understand their value, Episodic reviews are conducted as an evaluation of the code in question (and as many see it, of its author as well).  That's why they're called reviews.

The Charrette Protocol

Here's the Charrette Protocol, adapted for software development,

1. A developer or team (i.e., the requester) calls for a charrette whenever it is stuck or when they are working on some particularly tricky code or design.
2. A team of advisors designated by the requestor joins the charrette.
3. A moderator/facilitator is designated from the joint team to observe the charrette, ask questions along the way and keeps track of any action items.
4. The requester presents the "work in progress" while the advisors listen.
5. The requester states what it needs or wants from the charrette, thereby accepting the responsibility of focusing the discussion. This can take the form of a specific request or it can be as generic as "How can we make this better?" or "What should we do next?"
6. The advisors then discuss while the requester listens and takes notes. There are no hard and fast rules here. Occasionally (but not usually) the requester joins in the discussion process. The emphasis is on improving the work, which now belongs to the entire group. The atmosphere is one of "we're in this together to make a good thing even better."
7. When the requester gets what it needs from the advisors, he/she/they stop the process, briefly summarize what was gained, thank the advisors and moderator and return to the drawing board.

Empowering and Agile

The charrette flips the Episodic review on its head in that 1) the author or authoring team calls for it when they want feedback or help from others with a fresher perspective, different skills, etc. and 2) instead of waiting to review "finished" code, the charrette is done for work in progress.  As Kathy Juarez points out, this is "a low stakes/no stakes environment, where the requesting team has much to gain from the process and virtually nothing to lose."

The fact that charrettes are done around work in progress means that they can be done as often as needed and not at some mythical "end of coding."

Yeah for Twitter and Serendipity!

BTW, I found Kathy Juarez' write up through a @shelisrael retweet of a @paulallison post.  Interestingly, I found it through one of @paulallison's other posts, not the one retweeted by @shelisrael.