<?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: The Art and War of Estimating and Scheduling Software</title>
	<atom:link href="http://ardentdev.com/the-art-and-war-of-estimating-and-scheduling-software/feed/" rel="self" type="application/rss+xml" />
	<link>http://ardentdev.com/the-art-and-war-of-estimating-and-scheduling-software/</link>
	<description>For the Love of Code</description>
	<lastBuildDate>Tue, 27 Jul 2010 10:15:57 -0300</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: phloid domino</title>
		<link>http://ardentdev.com/the-art-and-war-of-estimating-and-scheduling-software/comment-page-1/#comment-22953</link>
		<dc:creator>phloid domino</dc:creator>
		<pubDate>Wed, 02 Apr 2008 02:25:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.ardentdev.com/blog/index.php/2007/08/29/the-art-and-war-of-estimating-and-scheduling-software/#comment-22953</guid>
		<description>Can&#039;t dispute the value of accurate estimates, nor the merit, on the surface, of trying to be &#039;scientific&#039; about tracking data and improving, etc, BUT...

Almost every discussion, blog, book, whatever on this topic ignores the elephant in the room:  the lack of good faith on the part of most managements of most software development organizations.

As long as the obsession with schedules prevails over all else, developers will feel pressure to make &#039;ambitious&#039; estimates.  Factor in that scope and requirements are never stable, so any correlations between original estimates and &#039;completion&#039; will always be moot.

The above describes more than 90% of all corporate software environments, and I speak from experience, having worked as either a contractor or employee at dozens of companies over 20 years, including well recognized big brand name software publishers. They are all the same.

It&#039;s the managers, stupid.</description>
		<content:encoded><![CDATA[<p>Can&#8217;t dispute the value of accurate estimates, nor the merit, on the surface, of trying to be &#8217;scientific&#8217; about tracking data and improving, etc, BUT&#8230;</p>
<p>Almost every discussion, blog, book, whatever on this topic ignores the elephant in the room:  the lack of good faith on the part of most managements of most software development organizations.</p>
<p>As long as the obsession with schedules prevails over all else, developers will feel pressure to make &#8216;ambitious&#8217; estimates.  Factor in that scope and requirements are never stable, so any correlations between original estimates and &#8216;completion&#8217; will always be moot.</p>
<p>The above describes more than 90% of all corporate software environments, and I speak from experience, having worked as either a contractor or employee at dozens of companies over 20 years, including well recognized big brand name software publishers. They are all the same.</p>
<p>It&#8217;s the managers, stupid.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: D'Arcy from Winnipeg</title>
		<link>http://ardentdev.com/the-art-and-war-of-estimating-and-scheduling-software/comment-page-1/#comment-2341</link>
		<dc:creator>D'Arcy from Winnipeg</dc:creator>
		<pubDate>Tue, 04 Sep 2007 14:33:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.ardentdev.com/blog/index.php/2007/08/29/the-art-and-war-of-estimating-and-scheduling-software/#comment-2341</guid>
		<description>Yeah...I don&#039;t think estimates will every truly be calculatable as long as humans are the machines that are doing the work (way too many variables in that), so it comes down to educated guesses. There&#039;s definately a human part of this too though:

- Is the developer someone with years of experience and a track record of good estimating?
- Is the developer someone who wants to please their boss and always understates certainty and complexity?
- Does the technology itself dictate the numbers without any human input?

For instance, I need a developer to execute a LINQ call to a collection of objects to return a subset for binding to a grid. Now that in itself doesn&#039;t sound terribly complex: we&#039;re not saying that we need a generic base-class to be created through a factory and execute a dynamically loaded LINQ statement against a collection of objects created via NHibernate...we just want a simple call executed against a pre-existing collection.

The complexity of this is probably relatively low...but the ability of the developer comes into play: How quickly does the dev pick up new technologies, have they written data-tier operations before, etc.

With LINQ being so new, there&#039;s great uncertainty as well: it doesn&#039;t *seem* complex, but then again we&#039;ve never touched it before so we don&#039;t really know what we&#039;re getting into.

I suppose that asking directly for a developers thoughts on Complexity and Uncertainty is just more discrete than asking &quot;How long do you thin it&#039;ll take you?&quot; With that question, a developer isn&#039;t really thinking through more telling trains of thought that asking &quot;How complex do you feel it is?&quot; and &quot;How certain are you that you can do it?&quot; can form.

D</description>
		<content:encoded><![CDATA[<p>Yeah&#8230;I don&#8217;t think estimates will every truly be calculatable as long as humans are the machines that are doing the work (way too many variables in that), so it comes down to educated guesses. There&#8217;s definately a human part of this too though:</p>
<p>- Is the developer someone with years of experience and a track record of good estimating?
- Is the developer someone who wants to please their boss and always understates certainty and complexity?
- Does the technology itself dictate the numbers without any human input?</p>
<p>For instance, I need a developer to execute a LINQ call to a collection of objects to return a subset for binding to a grid. Now that in itself doesn&#8217;t sound terribly complex: we&#8217;re not saying that we need a generic base-class to be created through a factory and execute a dynamically loaded LINQ statement against a collection of objects created via NHibernate&#8230;we just want a simple call executed against a pre-existing collection.</p>
<p>The complexity of this is probably relatively low&#8230;but the ability of the developer comes into play: How quickly does the dev pick up new technologies, have they written data-tier operations before, etc.</p>
<p>With LINQ being so new, there&#8217;s great uncertainty as well: it doesn&#8217;t *seem* complex, but then again we&#8217;ve never touched it before so we don&#8217;t really know what we&#8217;re getting into.</p>
<p>I suppose that asking directly for a developers thoughts on Complexity and Uncertainty is just more discrete than asking &#8220;How long do you thin it&#8217;ll take you?&#8221; With that question, a developer isn&#8217;t really thinking through more telling trains of thought that asking &#8220;How complex do you feel it is?&#8221; and &#8220;How certain are you that you can do it?&#8221; can form.</p>
<p>D</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tom Opgenorth</title>
		<link>http://ardentdev.com/the-art-and-war-of-estimating-and-scheduling-software/comment-page-1/#comment-2338</link>
		<dc:creator>Tom Opgenorth</dc:creator>
		<pubDate>Tue, 04 Sep 2007 13:29:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.ardentdev.com/blog/index.php/2007/08/29/the-art-and-war-of-estimating-and-scheduling-software/#comment-2338</guid>
		<description>Just curious, how did you arrive at 2/10 for Complexity and 8/10 for Uncertainty?  A educated guess?</description>
		<content:encoded><![CDATA[<p>Just curious, how did you arrive at 2/10 for Complexity and 8/10 for Uncertainty?  A educated guess?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: D'Arcy from Winnipeg</title>
		<link>http://ardentdev.com/the-art-and-war-of-estimating-and-scheduling-software/comment-page-1/#comment-2035</link>
		<dc:creator>D'Arcy from Winnipeg</dc:creator>
		<pubDate>Wed, 29 Aug 2007 20:00:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.ardentdev.com/blog/index.php/2007/08/29/the-art-and-war-of-estimating-and-scheduling-software/#comment-2035</guid>
		<description>One thing that I learned at my last gig was to factor in Uncertainty and Complexity into each item, which helps in determining estimates for a particular feature. So for example:

Developer - Fred
Knows VB.NET and SQL Server 2005, Intermediate Windows Developer

Work Item - Insert object data into database table from ASP.NET app written in C# into an Oracle database. All components must be written from scratch.

Complexity: Writing some data to a table isn&#039;t that complex...we&#039;re not throwing anything crazy at him. Out of 10, he rates this as a 2.

Certainty: Fred has never actually touched any of the required technologies, although he has worked with a .NET language and understands interacting with a RDBMS and its tools. However, his Uncertainty is very high since he hasn&#039;t actually touched either. Out of 10, he rates it an 8

So now we know that this task, for this resource, isn&#039;t complex but isn&#039;t a &quot;can do it in my sleep&quot; sort of thing. This information can help project managers drive out real estimtes from the hours quoted by the resources.

In face, one spreadsheet I&#039;ve seen used in a previous gig relied ENTIRELY on those two values to drive all other estimates. Features were distilled enough that you never had to worry about the feature size: all would be relative. If one was too big, that was a sign it needed to be refactored into smaller features.

Anyway, just adding to the conversation. Great post!

D</description>
		<content:encoded><![CDATA[<p>One thing that I learned at my last gig was to factor in Uncertainty and Complexity into each item, which helps in determining estimates for a particular feature. So for example:</p>
<p>Developer &#8211; Fred
Knows VB.NET and SQL Server 2005, Intermediate Windows Developer</p>
<p>Work Item &#8211; Insert object data into database table from ASP.NET app written in C# into an Oracle database. All components must be written from scratch.</p>
<p>Complexity: Writing some data to a table isn&#8217;t that complex&#8230;we&#8217;re not throwing anything crazy at him. Out of 10, he rates this as a 2.</p>
<p>Certainty: Fred has never actually touched any of the required technologies, although he has worked with a .NET language and understands interacting with a RDBMS and its tools. However, his Uncertainty is very high since he hasn&#8217;t actually touched either. Out of 10, he rates it an 8</p>
<p>So now we know that this task, for this resource, isn&#8217;t complex but isn&#8217;t a &#8220;can do it in my sleep&#8221; sort of thing. This information can help project managers drive out real estimtes from the hours quoted by the resources.</p>
<p>In face, one spreadsheet I&#8217;ve seen used in a previous gig relied ENTIRELY on those two values to drive all other estimates. Features were distilled enough that you never had to worry about the feature size: all would be relative. If one was too big, that was a sign it needed to be refactored into smaller features.</p>
<p>Anyway, just adding to the conversation. Great post!</p>
<p>D</p>
]]></content:encoded>
	</item>
</channel>
</rss>
