Comments for Agile Code Reviews: the Charrette Protocol at http://www.nearsoft.com , comment 1 to 4 out of 4 comments http://www.nearsoft.com Fri, 10 Sep 2010 13:18:14 +0100 FeedCreator 1.7.3 http://www.nearsoft.com/blog/agile-code-reviews-the-charrette-protocol.html#comment-136 Francisco, I agree that you'd have to be careful when deploying the Charrette Protocol. Developers have to have "conscious incompetence" and the culture has to support it. If people get punished (e.g., ridiculed) when asking for help, they won't do it, even when they are aware that they could use help. In fact, culture is the best teacher for things like this. If a junior developer sees the CTO call for her own Charrettes, then, naturally he'll call them, too. On the other hand, in a command-and-control culture, Charrettes probably will not work (i.e., they will not happen often, if at all). You are dead on the value of asking for help and the fact that the mere act of asking moves towards the solution. The main reason I am proposing this approach, is that, in my experience, Episodic Reviews are right up there with root canals and they either don't happen or, if they do, they are exhausting and oftentimes demoralizing. They are not very Agile, either, in that they are dependent of "finished code" (I don't know about you, but I have no idea what that is, really). If Reviews are happening and they are working, then by all means keep on doing them. Otherwise, the Charrette Protocol is a good alternative. - Matt Perez Thu, 04 Feb 2010 20:41:14 +0100 http://www.nearsoft.com/blog/agile-code-reviews-the-charrette-protocol.html#comment-135 Bob, You really have a talent for the succinct (I've been checking out your blog). I love how you put it, "separate ego from quality code." Yes, that's a big win of this technique. - Matt Perez Thu, 04 Feb 2010 20:40:33 +0100 http://www.nearsoft.com/blog/agile-code-reviews-the-charrette-protocol.html#comment-133 I did not know there was a name for this... sounds like the way a healthy team collaborates: Someone has a problem, and so he asks for help, other team members come to help, not to judge, the person with the problem explains it, and the others try to help... and eventually and the problem gets fixed (sometimes the even the act of explaining so helpful that by the time the person with the problem has explained it, she already knows the solution. ;D Now, while this does work (in my opinion) as an excellent practice to avoid getting stuck in a problem, I am not sure that it is a complete replacement for traditional code reviews, because it depends on the developer having "Conscious Incompetence" for the particular programming task at hand (she knows she might be doing something wrong). In other words, she needs to know she is getting into trouble. If the developer is at the "Unconscious Incompetence" level (she is not aware that what she is doing is wrong), she will not call for a charrette... and his mistakes will be ignored until they explode... probably in the customer face... It is for those cases that it is still valuable to have traditional code reviews... ;) - Francisco Thu, 04 Feb 2010 07:44:03 +0100 http://www.nearsoft.com/blog/agile-code-reviews-the-charrette-protocol.html#comment-128 Adopting the design charrette from architecture is an excellent idea. Thanks for the tip! The "control" aspect is key particularly on teams who haven't had the time together to build the level of trust necessary to separate ego from quality code. - Bob MacNeal Tue, 02 Feb 2010 03:50:02 +0100