<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.1" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Break Your Process Addiction</title>
	<link>http://blog.jtimothyking.com/2006/04/06/break-your-process-addiction</link>
	<description>Stories of a Self-published, Entrepreneurial Fiction Author (née Software Guy)</description>
	<pubDate>Thu, 28 Aug 2008 09:42:38 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.1</generator>
		<item>
		<title>By: Agile Executive &#187; Blog Archive &#187; Carnival of Agilists - 4/06/06</title>
		<link>http://blog.jtimothyking.com/2006/04/06/break-your-process-addiction#comment-8496</link>
		<dc:creator>Agile Executive &#187; Blog Archive &#187; Carnival of Agilists - 4/06/06</dc:creator>
		<pubDate>Wed, 27 Sep 2006 01:51:06 +0000</pubDate>
		<guid>http://blog.jtimothyking.com/2006/04/06/break-your-process-addiction#comment-8496</guid>
		<description>[...] Kicking off this week&#8217;s carnival is J. Timothy King - a new blogger to our community - trying to Break Your Process Addiction. Welcome! [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] Kicking off this week&#8217;s carnival is J. Timothy King - a new blogger to our community - trying to Break Your Process Addiction. Welcome! [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: silk and spinach</title>
		<link>http://blog.jtimothyking.com/2006/04/06/break-your-process-addiction#comment-13</link>
		<dc:creator>silk and spinach</dc:creator>
		<pubDate>Thu, 20 Apr 2006 15:37:00 +0000</pubDate>
		<guid>http://blog.jtimothyking.com/2006/04/06/break-your-process-addiction#comment-13</guid>
		<description>&lt;strong&gt;carnival of the agilists, 20-apr-06&lt;/strong&gt;

Welcome to the April 20th edition of the Carnival of Agilists - the blogroll pointing you to some of the latest thoughts in the agile community</description>
		<content:encoded><![CDATA[<p><strong>carnival of the agilists, 20-apr-06</strong></p>
<p>Welcome to the April 20th edition of the Carnival of Agilists - the blogroll pointing you to some of the latest thoughts in the agile community</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: J. Timothy King</title>
		<link>http://blog.jtimothyking.com/2006/04/06/break-your-process-addiction#comment-9</link>
		<dc:creator>J. Timothy King</dc:creator>
		<pubDate>Mon, 10 Apr 2006 12:56:26 +0000</pubDate>
		<guid>http://blog.jtimothyking.com/2006/04/06/break-your-process-addiction#comment-9</guid>
		<description>Yes, I agree with everything you say here. What if we're so busy, we don't have time for proper manual testing, either? (How many senior people on your team have checked in code without testing it? It happens all too often here.)

-TimK</description>
		<content:encoded><![CDATA[<p>Yes, I agree with everything you say here. What if we&#8217;re so busy, we don&#8217;t have time for proper manual testing, either? (How many senior people on your team have checked in code without testing it? It happens all too often here.)</p>
<p>-TimK</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Artem</title>
		<link>http://blog.jtimothyking.com/2006/04/06/break-your-process-addiction#comment-8</link>
		<dc:creator>Artem</dc:creator>
		<pubDate>Mon, 10 Apr 2006 08:11:54 +0000</pubDate>
		<guid>http://blog.jtimothyking.com/2006/04/06/break-your-process-addiction#comment-8</guid>
		<description>If the unit tests are not in place (e.g. because you company just doesn't use unit testing consistently), then fixing without a test for the tomorrow demo can be faster and is faster. Unless you keep the tests up to date and run them at least daily there is always an "easy path" to do the testing for your small fix manually. 

It does work and works well. It just works for the next week only. Two weeks later somebody else makes another fix that breaks your fix and there is no test in place to warn about it. However, for the next week the simple manual testing really works. After all usually it is just a manual examination of what a unit test would check automatically. And here the trap comes: if the manual test works for now, spend the time with testing later.</description>
		<content:encoded><![CDATA[<p>If the unit tests are not in place (e.g. because you company just doesn&#8217;t use unit testing consistently), then fixing without a test for the tomorrow demo can be faster and is faster. Unless you keep the tests up to date and run them at least daily there is always an &#8220;easy path&#8221; to do the testing for your small fix manually. </p>
<p>It does work and works well. It just works for the next week only. Two weeks later somebody else makes another fix that breaks your fix and there is no test in place to warn about it. However, for the next week the simple manual testing really works. After all usually it is just a manual examination of what a unit test would check automatically. And here the trap comes: if the manual test works for now, spend the time with testing later.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: J. Timothy King</title>
		<link>http://blog.jtimothyking.com/2006/04/06/break-your-process-addiction#comment-7</link>
		<dc:creator>J. Timothy King</dc:creator>
		<pubDate>Sun, 09 Apr 2006 01:39:00 +0000</pubDate>
		<guid>http://blog.jtimothyking.com/2006/04/06/break-your-process-addiction#comment-7</guid>
		<description>Hi, Artem. Thanks for writing. Yes, sometimes there is a real trade-off between a little more work now and a lot more later, but that's not the scenario I was describing. What I'm talking about is the &lt;em&gt;belief&lt;/em&gt; that a even little &lt;em&gt;can be&lt;/em&gt; saved now. It's the fact that we respond to pressure rather than actually making an intelligent choice.

I'm as lazy as the next guy. That's why I love unit tests. I love being able to accomplish more with less work and less frustration. And by skipping unit tests, I've introduced bugs, and this happens more often than I want to admit. So, I'm Tim, and I'm a recovering process addict. I need to remind myself constantly that building quality into the design&#8212;and that's what unit testing is about&#8212;seldom costs anything even in the short term, and never in the long term.

Sometimes I do hack together a solution, for example, but I know that the next time someone touches that code, he'll need to refactor it before he does anything else. Otherwise, the hack will turn into a bug-ridden maintenance nightmare.

Unit testing comes immediately to mind because that's a subject I've been thinking about at work. But we do the same thing with communication. ("Aw. I can't walk all the way over to my teammate's cubicle just to say 'Hello.' Not just now. I'm too busy.") We do it with estimation and retrospectives. We do it with the build procedure, because it's easier just to do it manually than to deal with automation issues. And then we have 3-month integration cycles (and slower release cycles), just because it takes a whole afternoon of developer time just to do a drop. At least I know each of these I have seen first hand, and I have been the sinner in some instances, a recovering sinner, saved by Grace.

-TimK</description>
		<content:encoded><![CDATA[<p>Hi, Artem. Thanks for writing. Yes, sometimes there is a real trade-off between a little more work now and a lot more later, but that&#8217;s not the scenario I was describing. What I&#8217;m talking about is the <em>belief</em> that a even little <em>can be</em> saved now. It&#8217;s the fact that we respond to pressure rather than actually making an intelligent choice.</p>
<p>I&#8217;m as lazy as the next guy. That&#8217;s why I love unit tests. I love being able to accomplish more with less work and less frustration. And by skipping unit tests, I&#8217;ve introduced bugs, and this happens more often than I want to admit. So, I&#8217;m Tim, and I&#8217;m a recovering process addict. I need to remind myself constantly that building quality into the design&mdash;and that&#8217;s what unit testing is about&mdash;seldom costs anything even in the short term, and never in the long term.</p>
<p>Sometimes I do hack together a solution, for example, but I know that the next time someone touches that code, he&#8217;ll need to refactor it before he does anything else. Otherwise, the hack will turn into a bug-ridden maintenance nightmare.</p>
<p>Unit testing comes immediately to mind because that&#8217;s a subject I&#8217;ve been thinking about at work. But we do the same thing with communication. (&#8221;Aw. I can&#8217;t walk all the way over to my teammate&#8217;s cubicle just to say &#8216;Hello.&#8217; Not just now. I&#8217;m too busy.&#8221;) We do it with estimation and retrospectives. We do it with the build procedure, because it&#8217;s easier just to do it manually than to deal with automation issues. And then we have 3-month integration cycles (and slower release cycles), just because it takes a whole afternoon of developer time just to do a drop. At least I know each of these I have seen first hand, and I have been the sinner in some instances, a recovering sinner, saved by Grace.</p>
<p>-TimK</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Artem</title>
		<link>http://blog.jtimothyking.com/2006/04/06/break-your-process-addiction#comment-6</link>
		<dc:creator>Artem</dc:creator>
		<pubDate>Sat, 08 Apr 2006 15:18:18 +0000</pubDate>
		<guid>http://blog.jtimothyking.com/2006/04/06/break-your-process-addiction#comment-6</guid>
		<description>True. Save now, loose later. *Sometimes* it can really be reasonable. Unfortunately our mind tends to avoid extra work "right now" too often</description>
		<content:encoded><![CDATA[<p>True. Save now, loose later. *Sometimes* it can really be reasonable. Unfortunately our mind tends to avoid extra work &#8220;right now&#8221; too often</p>
]]></content:encoded>
	</item>
</channel>
</rss>
