<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Agile Development At Latitude &#8211; A Progress Report</title>
	<atom:link href="http://blog.geocortex.com/2008/04/13/agile-development-at-latitude-a-progress-report/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.geocortex.com/2008/04/13/agile-development-at-latitude-a-progress-report/</link>
	<description>Web-based GIS, software development &#38; various other topics of interest to us.</description>
	<lastBuildDate>Sun, 05 Sep 2010 07:34:36 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Kevin Rintoul</title>
		<link>http://blog.geocortex.com/2008/04/13/agile-development-at-latitude-a-progress-report/comment-page-1/#comment-5567</link>
		<dc:creator>Kevin Rintoul</dc:creator>
		<pubDate>Tue, 27 May 2008 05:02:34 +0000</pubDate>
		<guid isPermaLink="false">/blogs/geocortex/archive/2008/04/13/agile-development-at-latitude-a-progress-report.aspx#comment-5567</guid>
		<description>Thanks for your comments. We use FxCop for automating a portion of our code reviews and it seems to work pretty well. We get the most benefit from using it, provided we use it from the beginning. It can be daunting task to apply the tools retroactively. One of the things we&#039;re doing on the Optimizer project is to mandate that our code runs cleanly through FxCop before a check-in. This seems to have had a very beneficial impact on our code quality.</description>
		<content:encoded><![CDATA[<p>Thanks for your comments. We use FxCop for automating a portion of our code reviews and it seems to work pretty well. We get the most benefit from using it, provided we use it from the beginning. It can be daunting task to apply the tools retroactively. One of the things we&#8217;re doing on the Optimizer project is to mandate that our code runs cleanly through FxCop before a check-in. This seems to have had a very beneficial impact on our code quality.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Stock</title>
		<link>http://blog.geocortex.com/2008/04/13/agile-development-at-latitude-a-progress-report/comment-page-1/#comment-5566</link>
		<dc:creator>Mark Stock</dc:creator>
		<pubDate>Wed, 14 May 2008 00:32:18 +0000</pubDate>
		<guid isPermaLink="false">/blogs/geocortex/archive/2008/04/13/agile-development-at-latitude-a-progress-report.aspx#comment-5566</guid>
		<description>I am constantly evaluating software and source code.  It sounds like you are on the right track.  What has helped take some of the drudgery out of the process is using Code Review software.  This is automated software that checks source code and highlights the most obvious problems.  I like to make automated code review a stage in the build process.

You state:  &quot;it is really difficult to review a feature consisting of several thousand lines of code scattered over a large number of files.&quot;  I like your honesty.  I think that this may be what the code review is about, honesty.  I don&#039;t know of any code review software as smart as you.  You are at least aware of the problem.  And, I see this particular type of problem more often than not.  This in itself is the review.  I am being honest about the mess I&#039;ve coded.  And, sometimes there is an advantage to coding a big bloated mess in that I can initially deliver software faster.  After a review, we can decide to refactor, rewrite, or do nothing.

Code reviews are great, and it&#039;s also important to move onward quickly.</description>
		<content:encoded><![CDATA[<p>I am constantly evaluating software and source code.  It sounds like you are on the right track.  What has helped take some of the drudgery out of the process is using Code Review software.  This is automated software that checks source code and highlights the most obvious problems.  I like to make automated code review a stage in the build process.</p>
<p>You state:  &#8220;it is really difficult to review a feature consisting of several thousand lines of code scattered over a large number of files.&#8221;  I like your honesty.  I think that this may be what the code review is about, honesty.  I don&#8217;t know of any code review software as smart as you.  You are at least aware of the problem.  And, I see this particular type of problem more often than not.  This in itself is the review.  I am being honest about the mess I&#8217;ve coded.  And, sometimes there is an advantage to coding a big bloated mess in that I can initially deliver software faster.  After a review, we can decide to refactor, rewrite, or do nothing.</p>
<p>Code reviews are great, and it&#8217;s also important to move onward quickly.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
