<?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: Arming Software Development Project Managers with Real Data</title>
	<atom:link href="http://www.accurev.com/blog//2007/11/30/arming-software-development-project-managers-with-real-data/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.accurev.com/blog/2007/11/30/arming-software-development-project-managers-with-real-data/</link>
	<description>Just another WordPress weblog</description>
	<lastBuildDate>Thu,  4 Mar 2010 23:02:33 -0600</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: BIRT and AccuWork &#171; Software Configuration Management</title>
		<link>http://www.accurev.com/blog/2007/11/30/arming-software-development-project-managers-with-real-data/comment-page-1/#comment-373</link>
		<dc:creator>BIRT and AccuWork &#171; Software Configuration Management</dc:creator>
		<pubDate>Thu, 06 Dec 2007 21:25:28 +0000</pubDate>
		<guid isPermaLink="false">http://blog.accurev.com/2007/11/30/arming-software-development-project-managers-with-real-data/#comment-373</guid>
		<description>[...] There are a number of data points that we generate as part of our development, and capturing all of them in a report format proves to be a surprisingly complex task. It is a task that gets little time and investment, as development goals are not report oriented, they are product delivery oriented. I&#8217;ve attempted to capture some of the more mundane details, and set aside future report details that require a larger effort. I&#8217;ll be describing what I&#8217;ve done to create the reports, but not really discuss about why or how to interpret the data. A discussion of some other data and what you can do with it can also be found here. [...]</description>
		<content:encoded><![CDATA[<p>[...] There are a number of data points that we generate as part of our development, and capturing all of them in a report format proves to be a surprisingly complex task. It is a task that gets little time and investment, as development goals are not report oriented, they are product delivery oriented. I&#8217;ve attempted to capture some of the more mundane details, and set aside future report details that require a larger effort. I&#8217;ll be describing what I&#8217;ve done to create the reports, but not really discuss about why or how to interpret the data. A discussion of some other data and what you can do with it can also be found here. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Josh</title>
		<link>http://www.accurev.com/blog/2007/11/30/arming-software-development-project-managers-with-real-data/comment-page-1/#comment-372</link>
		<dc:creator>Josh</dc:creator>
		<pubDate>Sun, 02 Dec 2007 21:01:01 +0000</pubDate>
		<guid isPermaLink="false">http://blog.accurev.com/2007/11/30/arming-software-development-project-managers-with-real-data/#comment-372</guid>
		<description>This is a good look at some of the factors that can be found using issue data. One thing I&#039;ve found with data like your churn information is that it is not just a candidate for reviews, but a strong indicator that to much functionality is found in a single file, especially if the changes are distributed across multiple developers.

Some factors I&#039;ve found are:

Methods are overly inclusive, used for lots of tasks. This (for me) is a strong indicator that they are prone to more subtle bugs, and besides reviews require stronger testing methods and are likely to cause regression errors. Great candidates for refactoring.

Methods aren&#039;t being distributed in the object model. Subclassing, creating more task oriented classes can make the code more usable both when adding more functionality and reviewing during development.</description>
		<content:encoded><![CDATA[<p>This is a good look at some of the factors that can be found using issue data. One thing I&#8217;ve found with data like your churn information is that it is not just a candidate for reviews, but a strong indicator that to much functionality is found in a single file, especially if the changes are distributed across multiple developers.</p>
<p>Some factors I&#8217;ve found are:</p>
<p>Methods are overly inclusive, used for lots of tasks. This (for me) is a strong indicator that they are prone to more subtle bugs, and besides reviews require stronger testing methods and are likely to cause regression errors. Great candidates for refactoring.</p>
<p>Methods aren&#8217;t being distributed in the object model. Subclassing, creating more task oriented classes can make the code more usable both when adding more functionality and reviewing during development.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
