<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/1.5.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Give Bugs A Chance</title>
	<link>http://blog.qualityaspect.com/2006/09/17/give-bugs-a-chance/</link>
	<description>Lidor Wyssocky's Blog on Optimizing Software Development</description>
	<pubDate>Wed, 20 Aug 2008 12:40:36 +0000</pubDate>
	<generator>http://wordpress.org/?v=1.5.2</generator>

	<item>
 		<title>Comment on Give Bugs A Chance by: Making a mountain out of a molehill (of bugs) &#171; //engtech</title>
		<link>http://blog.qualityaspect.com/2006/09/17/give-bugs-a-chance/#comment-1975</link>
		<pubDate>Wed, 27 Sep 2006 17:27:49 +0000</pubDate>
		<guid>http://blog.qualityaspect.com/2006/09/17/give-bugs-a-chance/#comment-1975</guid>
					<description>[...] &amp;#62;&amp;#62; All we are saying, is give bugs a chance. [1] No one wants to be hot and sweaty in a car with Kate Winslet unless they are being paid $2.5 million[3] or they are Melanie Lynskey. Especially if they have to listen to Celine Dion. [...]</description>
		<content:encoded><![CDATA[	<p>[&#8230;] &gt;&gt; All we are saying, is give bugs a chance. [1] No one wants to be hot and sweaty in a car with Kate Winslet unless they are being paid $2.5 million[3] or they are Melanie Lynskey. Especially if they have to listen to Celine Dion. [&#8230;]
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Give Bugs A Chance by: Blast those bugs away &#171; Mouli&#8217;s blog</title>
		<link>http://blog.qualityaspect.com/2006/09/17/give-bugs-a-chance/#comment-1881</link>
		<pubDate>Wed, 20 Sep 2006 16:55:43 +0000</pubDate>
		<guid>http://blog.qualityaspect.com/2006/09/17/give-bugs-a-chance/#comment-1881</guid>
					<description>[...] Read the whole post here. [...]</description>
		<content:encoded><![CDATA[	<p>[&#8230;] Read the whole post here. [&#8230;]
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Give Bugs A Chance by: Tom Harris</title>
		<link>http://blog.qualityaspect.com/2006/09/17/give-bugs-a-chance/#comment-1863</link>
		<pubDate>Tue, 19 Sep 2006 06:50:40 +0000</pubDate>
		<guid>http://blog.qualityaspect.com/2006/09/17/give-bugs-a-chance/#comment-1863</guid>
					<description>Even though I do tend to fix things around the house, what I choose to fix quickly and what I procrastinate about is telling. I like doing repairs when I know I will succeed. (So changing a lightbulb is generally an easy win.) The ones I delay are the ones that are difficult for me -- I don't know how to do them, don't have the experience, and may require outside help. Attacking those fixes sooner doesn't seem to make them easier to fix, nor does leaving them make them harder. I admit, though, that it makes it less pleasant to live in the house.

So in software, one question is: what can make one more able to fix difficult bugs when reported?

Meanwhile, regarding Arnon's comment about the broken windows theory, I lived in New York when they got rid of graffiti on the subways. It really did make a big difference.

So for software, my second question is: what can reduce the maximum difficulty of fixing a bug in your software?

For that one, people do have an answer, though don't always invest accordingly: good design.</description>
		<content:encoded><![CDATA[	<p>Even though I do tend to fix things around the house, what I choose to fix quickly and what I procrastinate about is telling. I like doing repairs when I know I will succeed. (So changing a lightbulb is generally an easy win.) The ones I delay are the ones that are difficult for me &#8212; I don&#8217;t know how to do them, don&#8217;t have the experience, and may require outside help. Attacking those fixes sooner doesn&#8217;t seem to make them easier to fix, nor does leaving them make them harder. I admit, though, that it makes it less pleasant to live in the house.</p>
	<p>So in software, one question is: what can make one more able to fix difficult bugs when reported?</p>
	<p>Meanwhile, regarding Arnon&#8217;s comment about the broken windows theory, I lived in New York when they got rid of graffiti on the subways. It really did make a big difference.</p>
	<p>So for software, my second question is: what can reduce the maximum difficulty of fixing a bug in your software?</p>
	<p>For that one, people do have an answer, though don&#8217;t always invest accordingly: good design.
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Give Bugs A Chance by: Arnon Rotem-Gal-Oz</title>
		<link>http://blog.qualityaspect.com/2006/09/17/give-bugs-a-chance/#comment-1850</link>
		<pubDate>Mon, 18 Sep 2006 18:07:42 +0000</pubDate>
		<guid>http://blog.qualityaspect.com/2006/09/17/give-bugs-a-chance/#comment-1850</guid>
					<description>&quot;But it gets even worse. The longer you live with the bugs, the harder they become to fix. &quot; 

Appropos the building image  - that is pretty much like the &quot;broken window theory&quot; http://en.wikipedia.org/wiki/Broken_windows_theory</description>
		<content:encoded><![CDATA[	<p>&#8220;But it gets even worse. The longer you live with the bugs, the harder they become to fix. &#8221; </p>
	<p>Appropos the building image  - that is pretty much like the &#8220;broken window theory&#8221; <a href='http://en.wikipedia.org/wiki/Broken_windows_theory' rel='nofollow'>http://en.wikipedia.org/wiki/Broken_windows_theory</a>
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Give Bugs A Chance by: Jeff Staddon</title>
		<link>http://blog.qualityaspect.com/2006/09/17/give-bugs-a-chance/#comment-1849</link>
		<pubDate>Mon, 18 Sep 2006 17:31:57 +0000</pubDate>
		<guid>http://blog.qualityaspect.com/2006/09/17/give-bugs-a-chance/#comment-1849</guid>
					<description>From what I've seen, &quot;Hard&quot; bugs are usually caused by flawed architecture.  In most of those cases the architecture doesn't align with the business model.  This is a huge problem since if the flaw isn't fixed, tiny changes to the business model may (usually) become huge problems in the code.

Thus: the two &quot;laws&quot; of architecture flaws:
1) They are hard to fix
2) They will keep producing new and unforeseen bugs until they are fixed

To properly evaluate their cost (to prioritize), requires knowing what unforeseen bugs the flaw will produce over time.  This is:  impossible!

My rule--give extra preference to fixing architecture bugs (by at least a factor of 10 if not 100).  In the end it will pay off.</description>
		<content:encoded><![CDATA[	<p>From what I&#8217;ve seen, &#8220;Hard&#8221; bugs are usually caused by flawed architecture.  In most of those cases the architecture doesn&#8217;t align with the business model.  This is a huge problem since if the flaw isn&#8217;t fixed, tiny changes to the business model may (usually) become huge problems in the code.</p>
	<p>Thus: the two &#8220;laws&#8221; of architecture flaws:<br />
1) They are hard to fix<br />
2) They will keep producing new and unforeseen bugs until they are fixed</p>
	<p>To properly evaluate their cost (to prioritize), requires knowing what unforeseen bugs the flaw will produce over time.  This is:  impossible!</p>
	<p>My rule&#8211;give extra preference to fixing architecture bugs (by at least a factor of 10 if not 100).  In the end it will pay off.
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Give Bugs A Chance by: Alejandro</title>
		<link>http://blog.qualityaspect.com/2006/09/17/give-bugs-a-chance/#comment-1842</link>
		<pubDate>Mon, 18 Sep 2006 10:26:32 +0000</pubDate>
		<guid>http://blog.qualityaspect.com/2006/09/17/give-bugs-a-chance/#comment-1842</guid>
					<description>Nice =)</description>
		<content:encoded><![CDATA[	<p>Nice =)
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
