<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/1.5.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: The Reassuring Review</title>
	<link>http://blog.qualityaspect.com/2006/08/17/the-reassuring-review/</link>
	<description>Lidor Wyssocky's Blog on Optimizing Software Development</description>
	<pubDate>Thu, 28 Aug 2008 11:52:32 +0000</pubDate>
	<generator>http://wordpress.org/?v=1.5.2</generator>

	<item>
 		<title>Comment on The Reassuring Review by: Dave Nicolette</title>
		<link>http://blog.qualityaspect.com/2006/08/17/the-reassuring-review/#comment-1370</link>
		<pubDate>Mon, 21 Aug 2006 14:47:19 +0000</pubDate>
		<guid>http://blog.qualityaspect.com/2006/08/17/the-reassuring-review/#comment-1370</guid>
					<description>Great insights, Lidor. As a frequent reader of Ed's blog, I gather that he has been introducing agile practices in his organization in an incremental way. Seems to me code reviews could be a great tool for advancing that effort. You suggest &quot;reviewing more subtle issues.&quot; Let's offer a more specific recommendation. 

TDD is one of the most beneficial development practices people are using these days. The third step in the TDD cycle - refactoring - seems to create challenges (there's that word again) for many developers. Now that Ed's teams are past the point of making a lot of basic errors, what about using code reviews to mentor developers on exactlyhow to recognize when code needs refactoring, and then just what they need to do with the code to clean it up? 

I suggest Joshua Kerievsky's book, Refactoring to Patterns, for some practical guidance. Code reviews could be an effective tool to help developers apply those practices. It's not something you can pick up in five minutes of casual reading. The repeated sanity checks and reinforcement provided by code reviews seem like a great way to build those skills in an organization. 

As the development staff continues to improve its knowledge and effectiveness, continue raising the bar at code reviews to help them reach the next level. There shouldn't be a time when code reviews become obsolete, as long as you're targeting the right level of knowlege for the particular team.</description>
		<content:encoded><![CDATA[	<p>Great insights, Lidor. As a frequent reader of Ed&#8217;s blog, I gather that he has been introducing agile practices in his organization in an incremental way. Seems to me code reviews could be a great tool for advancing that effort. You suggest &#8220;reviewing more subtle issues.&#8221; Let&#8217;s offer a more specific recommendation. </p>
	<p>TDD is one of the most beneficial development practices people are using these days. The third step in the TDD cycle - refactoring - seems to create challenges (there&#8217;s that word again) for many developers. Now that Ed&#8217;s teams are past the point of making a lot of basic errors, what about using code reviews to mentor developers on exactlyhow to recognize when code needs refactoring, and then just what they need to do with the code to clean it up? </p>
	<p>I suggest Joshua Kerievsky&#8217;s book, Refactoring to Patterns, for some practical guidance. Code reviews could be an effective tool to help developers apply those practices. It&#8217;s not something you can pick up in five minutes of casual reading. The repeated sanity checks and reinforcement provided by code reviews seem like a great way to build those skills in an organization. </p>
	<p>As the development staff continues to improve its knowledge and effectiveness, continue raising the bar at code reviews to help them reach the next level. There shouldn&#8217;t be a time when code reviews become obsolete, as long as you&#8217;re targeting the right level of knowlege for the particular team.
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on The Reassuring Review by: Lidor Wyssocky</title>
		<link>http://blog.qualityaspect.com/2006/08/17/the-reassuring-review/#comment-1357</link>
		<pubDate>Sun, 20 Aug 2006 09:28:07 +0000</pubDate>
		<guid>http://blog.qualityaspect.com/2006/08/17/the-reassuring-review/#comment-1357</guid>
					<description>Hi Ed, 

The question is are you utilizing your reviews to their full extent. You say that basic mistakes are rare. That's great. Now, how about reviewing more subtle issues? How about reviewing design decisions made by developers? How about trying to improve the quality of unit tests by reviewing them? 

I truly believe almost every developer can benefit from systematic reviews as long as their goal is to create improvement and increase professionalism. 

Lidor</description>
		<content:encoded><![CDATA[	<p>Hi Ed, </p>
	<p>The question is are you utilizing your reviews to their full extent. You say that basic mistakes are rare. That&#8217;s great. Now, how about reviewing more subtle issues? How about reviewing design decisions made by developers? How about trying to improve the quality of unit tests by reviewing them? </p>
	<p>I truly believe almost every developer can benefit from systematic reviews as long as their goal is to create improvement and increase professionalism. </p>
	<p>Lidor
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on The Reassuring Review by: Ed Gibbs</title>
		<link>http://blog.qualityaspect.com/2006/08/17/the-reassuring-review/#comment-1356</link>
		<pubDate>Sun, 20 Aug 2006 04:58:15 +0000</pubDate>
		<guid>http://blog.qualityaspect.com/2006/08/17/the-reassuring-review/#comment-1356</guid>
					<description>After getting past the point of introducing code reviews, I do have a slight fear that they will seem less neccessary because developers are rarely making basic mistakes anymore.  Every once in a while we don't find much in a particular review and of course the value question pops up even if no one verbalizes it.

I've managed to avoid the first two points so far.  Everyone on the team reviews everyone's code and I'm on some of the reviews and not others.  As everyone becomes more accustomed to it I plan to drop off almost all the reviews.</description>
		<content:encoded><![CDATA[	<p>After getting past the point of introducing code reviews, I do have a slight fear that they will seem less neccessary because developers are rarely making basic mistakes anymore.  Every once in a while we don&#8217;t find much in a particular review and of course the value question pops up even if no one verbalizes it.</p>
	<p>I&#8217;ve managed to avoid the first two points so far.  Everyone on the team reviews everyone&#8217;s code and I&#8217;m on some of the reviews and not others.  As everyone becomes more accustomed to it I plan to drop off almost all the reviews.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
