<?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 Chronicles #7: Bugs, Unit Testing, and Throughput	</title>
	<atom:link href="https://jessewarden.com/2008/12/agile-bugs-unit-testing-throughput.html/feed" rel="self" type="application/rss+xml" />
	<link>https://jessewarden.com/2008/12/agile-bugs-unit-testing-throughput.html</link>
	<description>Software &#124; Fitness &#124; Gaming</description>
	<lastBuildDate>Sat, 06 Jul 2013 01:34:34 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	
	<item>
		<title>
		By: JesterXL		</title>
		<link>https://jessewarden.com/2008/12/agile-bugs-unit-testing-throughput.html/comment-page-1#comment-194138</link>

		<dc:creator><![CDATA[JesterXL]]></dc:creator>
		<pubDate>Sun, 30 Aug 2009 19:06:52 +0000</pubDate>
		<guid isPermaLink="false">http://jessewarden.com/?p=1305#comment-194138</guid>

					<description><![CDATA[@nicemandan My feelings, exactly.  I still agree TDD is worth doing on the services.  They say you shouldn&#039;t run tests against real webservices.  I, however, have found it extremely useful.  Since the weakest link in the chain for a RIA is Factories, the service classes that actually hit real back-ends are the 2nd.  I can fix the factories, I can&#039;t fix the services.  That, and confirming they are in fact a problem, quickly and assuredly, is extremely helpful, both during development and over time.

...everything else?  Yeah, exactly, I have to get things done by end of sprint, and if they don&#039;t work in another sprint, saying TDD would of saved me is bs because I wouldn&#039;t of gotten the burn rate I got NOT using TDD.

Then again, I&#039;m still learning, so maybe.....]]></description>
			<content:encoded><![CDATA[<p>@nicemandan My feelings, exactly.  I still agree TDD is worth doing on the services.  They say you shouldn&#8217;t run tests against real webservices.  I, however, have found it extremely useful.  Since the weakest link in the chain for a RIA is Factories, the service classes that actually hit real back-ends are the 2nd.  I can fix the factories, I can&#8217;t fix the services.  That, and confirming they are in fact a problem, quickly and assuredly, is extremely helpful, both during development and over time.</p>
<p>&#8230;everything else?  Yeah, exactly, I have to get things done by end of sprint, and if they don&#8217;t work in another sprint, saying TDD would of saved me is bs because I wouldn&#8217;t of gotten the burn rate I got NOT using TDD.</p>
<p>Then again, I&#8217;m still learning, so maybe&#8230;..</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: nicemandan		</title>
		<link>https://jessewarden.com/2008/12/agile-bugs-unit-testing-throughput.html/comment-page-1#comment-194135</link>

		<dc:creator><![CDATA[nicemandan]]></dc:creator>
		<pubDate>Sun, 30 Aug 2009 18:34:12 +0000</pubDate>
		<guid isPermaLink="false">http://jessewarden.com/?p=1305#comment-194135</guid>

					<description><![CDATA[I&#039;m new to TDD as well and I&#039;ve found it incredibly difficult to balance the agile &#039;git-er-done&#039; ethos with TDD. 

To build a feature from a decent set of test takes time, but then the pressure to have a working feature ready by the end of a sprint usually overrides having the tests in place.

This negates using TDD at all if the time pressure is such that you end up having to hack a feature together.

It feels to me that these two forces tend to pull the project apart and developers usually withdraw back to the quick hacks they know and  do best.]]></description>
			<content:encoded><![CDATA[<p>I&#8217;m new to TDD as well and I&#8217;ve found it incredibly difficult to balance the agile &#8216;git-er-done&#8217; ethos with TDD. </p>
<p>To build a feature from a decent set of test takes time, but then the pressure to have a working feature ready by the end of a sprint usually overrides having the tests in place.</p>
<p>This negates using TDD at all if the time pressure is such that you end up having to hack a feature together.</p>
<p>It feels to me that these two forces tend to pull the project apart and developers usually withdraw back to the quick hacks they know and  do best.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Getting Advanced in Flex &#124; der hess		</title>
		<link>https://jessewarden.com/2008/12/agile-bugs-unit-testing-throughput.html/comment-page-1#comment-170793</link>

		<dc:creator><![CDATA[Getting Advanced in Flex &#124; der hess]]></dc:creator>
		<pubDate>Sat, 09 May 2009 10:09:49 +0000</pubDate>
		<guid isPermaLink="false">http://jessewarden.com/?p=1305#comment-170793</guid>

					<description><![CDATA[[...] Agile Chronicles #7: Bugs, Unit Testing, and Throughput [...]]]></description>
			<content:encoded><![CDATA[<p>[&#8230;] Agile Chronicles #7: Bugs, Unit Testing, and Throughput [&#8230;]</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Nirth		</title>
		<link>https://jessewarden.com/2008/12/agile-bugs-unit-testing-throughput.html/comment-page-1#comment-146668</link>

		<dc:creator><![CDATA[Nirth]]></dc:creator>
		<pubDate>Mon, 05 Jan 2009 05:26:05 +0000</pubDate>
		<guid isPermaLink="false">http://jessewarden.com/?p=1305#comment-146668</guid>

					<description><![CDATA[Thanks for this series of articles.]]></description>
			<content:encoded><![CDATA[<p>Thanks for this series of articles.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Simon Hartley		</title>
		<link>https://jessewarden.com/2008/12/agile-bugs-unit-testing-throughput.html/comment-page-1#comment-145913</link>

		<dc:creator><![CDATA[Simon Hartley]]></dc:creator>
		<pubDate>Thu, 01 Jan 2009 13:04:26 +0000</pubDate>
		<guid isPermaLink="false">http://jessewarden.com/?p=1305#comment-145913</guid>

					<description><![CDATA[Here&#039;s a link dealing with the pace of development in sprints:
http://www.infoq.com/news/2008/11/sprint-misnomer]]></description>
			<content:encoded><![CDATA[<p>Here&#8217;s a link dealing with the pace of development in sprints:<br />
<a href="http://www.infoq.com/news/2008/11/sprint-misnomer" rel="nofollow ugc">http://www.infoq.com/news/2008/11/sprint-misnomer</a></p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
