<?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: Do you have enough oil?</title>
	<atom:link href="http://andypalmer.com/2009/03/do-you-have-enough-oil/feed/" rel="self" type="application/rss+xml" />
	<link>http://andypalmer.com/2009/03/do-you-have-enough-oil/</link>
	<description>Views on software, technology, consulting and business process</description>
	<lastBuildDate>Sun, 31 Jan 2010 16:31:55 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Rob Myers</title>
		<link>http://andypalmer.com/2009/03/do-you-have-enough-oil/comment-page-1/#comment-898</link>
		<dc:creator>Rob Myers</dc:creator>
		<pubDate>Tue, 28 Apr 2009 23:05:11 +0000</pubDate>
		<guid isPermaLink="false">http://andypalmer.com/?p=58#comment-898</guid>
		<description>Perfect analogy!

I just gave a talk last night on the business value of TDD and particularly refactoring, and I find that--in order to get real buy-in--I&#039;ve had to finish this particular talk with three actual first-person stories about how the team I was on turned a sudden, surprising, and &quot;architecturally challenging&quot; story into over $100,000/year savings or revenue in a matter of days.  I know for a fact that all three of those would have ended in disappointment if we hadn&#039;t been completely covered with fast, automated regression tests, or hadn&#039;t been refactoring with a very low tolerance for subtle code-smells.  (That was one point of the talk I aimed at developers:  On a TDD team, you&#039;re not refactoring messy code, you&#039;re cleaning CLEAN code.  Like a sushi kitchen, you never leave it even a little messy.)</description>
		<content:encoded><![CDATA[<p>Perfect analogy!</p>
<p>I just gave a talk last night on the business value of TDD and particularly refactoring, and I find that&#8211;in order to get real buy-in&#8211;I&#8217;ve had to finish this particular talk with three actual first-person stories about how the team I was on turned a sudden, surprising, and &#8220;architecturally challenging&#8221; story into over $100,000/year savings or revenue in a matter of days.  I know for a fact that all three of those would have ended in disappointment if we hadn&#8217;t been completely covered with fast, automated regression tests, or hadn&#8217;t been refactoring with a very low tolerance for subtle code-smells.  (That was one point of the talk I aimed at developers:  On a TDD team, you&#8217;re not refactoring messy code, you&#8217;re cleaning CLEAN code.  Like a sushi kitchen, you never leave it even a little messy.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve C</title>
		<link>http://andypalmer.com/2009/03/do-you-have-enough-oil/comment-page-1/#comment-168</link>
		<dc:creator>Steve C</dc:creator>
		<pubDate>Sat, 21 Mar 2009 03:24:17 +0000</pubDate>
		<guid isPermaLink="false">http://andypalmer.com/?p=58#comment-168</guid>
		<description>Maybe even more notable, at sxsw I went to a panel on scaling webapps and was given this exact line of reasoning by some obviously competent dev leads from successful internet companies.  &quot;We&#039;re a startup.  We&#039;re resource-constrained.  We don&#039;t have time to write tests&quot;.

I don&#039;t want to ridicule these people - you have your set of experiences and you can&#039;t have absorbed everything the development world has to offer.

But we know that we write tests precisely because we&#039;re time-constrained.  I think this should get more emphasis than it does: a well-crafted, fast-running unit test suite is an incredibly powerful productivity tool.  If your time horizons are &gt; 1 month, your team will spend a punishing amount of time reorienting the codebase to accommodate changes and new features if correctness must be proven at human-using-a-browser speed.  For a modern startup it could very well mean death.</description>
		<content:encoded><![CDATA[<p>Maybe even more notable, at sxsw I went to a panel on scaling webapps and was given this exact line of reasoning by some obviously competent dev leads from successful internet companies.  &#8220;We&#8217;re a startup.  We&#8217;re resource-constrained.  We don&#8217;t have time to write tests&#8221;.</p>
<p>I don&#8217;t want to ridicule these people &#8211; you have your set of experiences and you can&#8217;t have absorbed everything the development world has to offer.</p>
<p>But we know that we write tests precisely because we&#8217;re time-constrained.  I think this should get more emphasis than it does: a well-crafted, fast-running unit test suite is an incredibly powerful productivity tool.  If your time horizons are &gt; 1 month, your team will spend a punishing amount of time reorienting the codebase to accommodate changes and new features if correctness must be proven at human-using-a-browser speed.  For a modern startup it could very well mean death.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
