<?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: Wild Theory Driven Debugging</title>
	<atom:link href="http://www.caffeinatedcoder.com/wild-theory-driven-debugging/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.caffeinatedcoder.com/wild-theory-driven-debugging/</link>
	<description>A Grande, Triple Shot, Non-Fat Core Dump by Russell Ball</description>
	<lastBuildDate>Wed, 01 Feb 2012 19:33:39 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.3</generator>
	<item>
		<title>By: So You Think YOU&#8217;RE a Geek? &#124; Caffeinated Coder</title>
		<link>http://www.caffeinatedcoder.com/wild-theory-driven-debugging/comment-page-1/#comment-634</link>
		<dc:creator>So You Think YOU&#8217;RE a Geek? &#124; Caffeinated Coder</dc:creator>
		<pubDate>Mon, 10 Mar 2008 08:27:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.caffeinatedcoder.com/wild-theory-driven-debugging/#comment-634</guid>
		<description>[...] side, that means that it won&#8217;t be long before you&#8217;ll be able to stop blaming those difficult to troubleshoot software glitches on mundane things like firewalls and network blips and start pulling out some truly impressive [...]</description>
		<content:encoded><![CDATA[<p>[...] side, that means that it won&#8217;t be long before you&#8217;ll be able to stop blaming those difficult to troubleshoot software glitches on mundane things like firewalls and network blips and start pulling out some truly impressive [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Russell Ball</title>
		<link>http://www.caffeinatedcoder.com/wild-theory-driven-debugging/comment-page-1/#comment-233</link>
		<dc:creator>Russell Ball</dc:creator>
		<pubDate>Mon, 03 Sep 2007 20:05:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.caffeinatedcoder.com/wild-theory-driven-debugging/#comment-233</guid>
		<description>Perhaps &quot;Under the Developer&#039;s control&quot; wasn&#039;t the right phrase to use here. I was more referring to the situation where you have a segregation of responsibilities so that developers only investigate application related issues and an IT Pros will investigate OS or network problems. It is not that a developer is powerless to investigate and fix these issues, but that he or she could decline to do it because they feel it is not their responsibility because underlying problem does not lie on their side of the fence. Although some problems can be resolved faster with this type of segregation due to greater expertise, I think most problems get resolved much more slowly because of the &quot;hot potato&quot; syndrome where each group claims that the problem exist on the other side of the fence. I can accept that people can legitimately disagree about the cause of an issue, but I would at least expect each side would provide evidence for a theory such as event logs, tracing tools, diagnostic software, or Knowledge Base articles before throwing up their arms. My frustration comes into play when theories are tossed around that make it the other person&#039;s problem without any effort to first verify the facts.&lt;br /&gt;&lt;br /&gt;</description>
		<content:encoded><![CDATA[<p>Perhaps &#8220;Under the Developer&#8217;s control&#8221; wasn&#8217;t the right phrase to use here. I was more referring to the situation where you have a segregation of responsibilities so that developers only investigate application related issues and an IT Pros will investigate OS or network problems. It is not that a developer is powerless to investigate and fix these issues, but that he or she could decline to do it because they feel it is not their responsibility because underlying problem does not lie on their side of the fence. Although some problems can be resolved faster with this type of segregation due to greater expertise, I think most problems get resolved much more slowly because of the &#8220;hot potato&#8221; syndrome where each group claims that the problem exist on the other side of the fence. I can accept that people can legitimately disagree about the cause of an issue, but I would at least expect each side would provide evidence for a theory such as event logs, tracing tools, diagnostic software, or Knowledge Base articles before throwing up their arms. My frustration comes into play when theories are tossed around that make it the other person&#8217;s problem without any effort to first verify the facts.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: YG</title>
		<link>http://www.caffeinatedcoder.com/wild-theory-driven-debugging/comment-page-1/#comment-232</link>
		<dc:creator>YG</dc:creator>
		<pubDate>Mon, 03 Sep 2007 06:30:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.caffeinatedcoder.com/wild-theory-driven-debugging/#comment-232</guid>
		<description>I&#039;m not sure if I get this methodology.  If the the problem really isn&#039;t under the control of the developer, then is it a good practice to pay that developer to &quot;debug&quot; his software in an environment that he has little or no control?  (And that really isn&#039;t debugging, that&#039;s trouble-shooting).  Sounds like the reall problem in the WTDD theory is not providing developers with a stable environment to write and test their applications.  </description>
		<content:encoded><![CDATA[<p>I&#8217;m not sure if I get this methodology.  If the the problem really isn&#8217;t under the control of the developer, then is it a good practice to pay that developer to &#8220;debug&#8221; his software in an environment that he has little or no control?  (And that really isn&#8217;t debugging, that&#8217;s trouble-shooting).  Sounds like the reall problem in the WTDD theory is not providing developers with a stable environment to write and test their applications.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robz</title>
		<link>http://www.caffeinatedcoder.com/wild-theory-driven-debugging/comment-page-1/#comment-230</link>
		<dc:creator>Robz</dc:creator>
		<pubDate>Tue, 17 Jul 2007 14:01:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.caffeinatedcoder.com/wild-theory-driven-debugging/#comment-230</guid>
		<description> If something worked before you released and now it doesn&#039;t, it&#039;s pretty peculiar to think something OTHER than your code caused the problem.  The correlation is just too strong to deny...unless you never take responsibility, or you have a big enough ego to think everything you write walks on water.</description>
		<content:encoded><![CDATA[<p>If something worked before you released and now it doesn&#8217;t, it&#8217;s pretty peculiar to think something OTHER than your code caused the problem.  The correlation is just too strong to deny&#8230;unless you never take responsibility, or you have a big enough ego to think everything you write walks on water.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dewayne Christensen</title>
		<link>http://www.caffeinatedcoder.com/wild-theory-driven-debugging/comment-page-1/#comment-231</link>
		<dc:creator>Dewayne Christensen</dc:creator>
		<pubDate>Wed, 11 Jul 2007 21:57:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.caffeinatedcoder.com/wild-theory-driven-debugging/#comment-231</guid>
		<description>I can&#039;t tell you how many times I&#039;ve had this lesson reinforced: Assumption #1 of the well-honed developer is &quot;It&#039;s my own fault.&quot; (by watching _other_ people make the opposite assumption, of course...)&lt;br /&gt;</description>
		<content:encoded><![CDATA[<p>I can&#8217;t tell you how many times I&#8217;ve had this lesson reinforced: Assumption #1 of the well-honed developer is &#8220;It&#8217;s my own fault.&#8221; (by watching _other_ people make the opposite assumption, of course&#8230;)</p>
]]></content:encoded>
	</item>
</channel>
</rss>

