<?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"
	>
<channel>
	<title>Comments on: Fixing bugs is not equivalent to fixing design.</title>
	<atom:link href="http://www.dexodesign.com/2007/11/30/fixing-bugs-is-not-equivalent-to-fixing-design/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.dexodesign.com/2007/11/30/fixing-bugs-is-not-equivalent-to-fixing-design/</link>
	<description>Russell Wilson's blog about incremental/evolutionary design, navigation, layout, interaction design, information design and all things "software interface".</description>
	<pubDate>Sat, 22 Nov 2008 22:27:01 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: Samus_</title>
		<link>http://www.dexodesign.com/2007/11/30/fixing-bugs-is-not-equivalent-to-fixing-design/#comment-82</link>
		<dc:creator>Samus_</dc:creator>
		<pubDate>Sun, 16 Dec 2007 23:10:00 +0000</pubDate>
		<guid isPermaLink="false">http://blog.dexodesign.com/2007/11/fixing-bugs-is-not-equivalent-to-fixing-design/#comment-82</guid>
		<description>well, whatever the situation is hardware defects involve hardware pieces that must be replaced, that's obviously more expensive than "just" salary payment (which you have in both cases) I think they don't expend time testing and designing because they don't give a damn about what one has to do to "fix" those things, in fact they usually don't even know! now on the difference between bug and design well, a change in desing might lead to a new version (even if it not a real one) and that's a place for innovation, a well profitable marketing concept so I don't think design errors are worse than real bugs, real bugs or code problems lead to malfunctioning where interfase problems lead to discomfort which again, can be used a way to show "support" and "feedback" from the company to it's users.</description>
		<content:encoded><![CDATA[<p>well, whatever the situation is hardware defects involve hardware pieces that must be replaced, that&#8217;s obviously more expensive than &#8220;just&#8221; salary payment (which you have in both cases) I think they don&#8217;t expend time testing and designing because they don&#8217;t give a damn about what one has to do to &#8220;fix&#8221; those things, in fact they usually don&#8217;t even know! now on the difference between bug and design well, a change in desing might lead to a new version (even if it not a real one) and that&#8217;s a place for innovation, a well profitable marketing concept so I don&#8217;t think design errors are worse than real bugs, real bugs or code problems lead to malfunctioning where interfase problems lead to discomfort which again, can be used a way to show &#8220;support&#8221; and &#8220;feedback&#8221; from the company to it&#8217;s users.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://www.dexodesign.com/2007/11/30/fixing-bugs-is-not-equivalent-to-fixing-design/#comment-74</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Wed, 05 Dec 2007 13:59:00 +0000</pubDate>
		<guid isPermaLink="false">http://blog.dexodesign.com/2007/11/fixing-bugs-is-not-equivalent-to-fixing-design/#comment-74</guid>
		<description>&lt;i&gt;That's what so many executives are really thinking, aren't they? Build it, test it, get it&lt;br/&gt;out the door, and then ship fixes as necessary. Time to market, fix later.&lt;/i&gt;&lt;br/&gt;&lt;br/&gt;That sadly is indeed what some managers think. Its true to some extent at my company. So why is this? To me the answer is easy - because the metrics by which a project deliver are measured has too few dimensions. The end date dominates everything. There is no closure on such things as customer acceptance, defect rates, defect severities, etc. These take resources to measure AFTER the release, and by then, well, everyone is thinking about the next release.&lt;br/&gt;&lt;br/&gt;The only way to stop this nonsense is to tie managerial bonuses and such to hard, &lt;b&gt;measurable&lt;/b&gt; product quality.&lt;br/&gt;&lt;br/&gt;Nuff said.&lt;br/&gt;&lt;br/&gt;AllanC</description>
		<content:encoded><![CDATA[<p><i>That&#8217;s what so many executives are really thinking, aren&#8217;t they? Build it, test it, get it<br />out the door, and then ship fixes as necessary. Time to market, fix later.</i></p>
<p>That sadly is indeed what some managers think. Its true to some extent at my company. So why is this? To me the answer is easy - because the metrics by which a project deliver are measured has too few dimensions. The end date dominates everything. There is no closure on such things as customer acceptance, defect rates, defect severities, etc. These take resources to measure AFTER the release, and by then, well, everyone is thinking about the next release.</p>
<p>The only way to stop this nonsense is to tie managerial bonuses and such to hard, <b>measurable</b> product quality.</p>
<p>Nuff said.</p>
<p>AllanC</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://www.dexodesign.com/2007/11/30/fixing-bugs-is-not-equivalent-to-fixing-design/#comment-73</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Tue, 04 Dec 2007 21:08:00 +0000</pubDate>
		<guid isPermaLink="false">http://blog.dexodesign.com/2007/11/fixing-bugs-is-not-equivalent-to-fixing-design/#comment-73</guid>
		<description>A long time ago in a galaxy far, far away, I was an electrical engineer. &lt;br/&gt;&lt;br/&gt;One of the things they drummed into our heads then was that you needed to find mistakes as early as possible, as the cost went up ten-fold as you got closer to deployment. Namely, the cost of finding a defect in the field was 10X finding it in QA, which was 10X finding it in design validation, which was 10X ....&lt;br/&gt;&lt;br/&gt;Now this is talking about hardware costs which might be argued to be a lot higher than software costs (not that I agree with that). Has anyone heard of such a cost estimate for software defects found in design, implementation, unit test, feature test, system test, final QA, and the field? &lt;br/&gt;&lt;br/&gt;In addition, most people focus on the cost of implementing a fix, but I am not aware of anyone quantifying the total cost to a company in lost sales, company image, delayed purchases, etc.&lt;br/&gt;&lt;br/&gt;Pipe up if you know better.&lt;br/&gt;&lt;br/&gt;AllanC</description>
		<content:encoded><![CDATA[<p>A long time ago in a galaxy far, far away, I was an electrical engineer. </p>
<p>One of the things they drummed into our heads then was that you needed to find mistakes as early as possible, as the cost went up ten-fold as you got closer to deployment. Namely, the cost of finding a defect in the field was 10X finding it in QA, which was 10X finding it in design validation, which was 10X &#8230;.</p>
<p>Now this is talking about hardware costs which might be argued to be a lot higher than software costs (not that I agree with that). Has anyone heard of such a cost estimate for software defects found in design, implementation, unit test, feature test, system test, final QA, and the field? </p>
<p>In addition, most people focus on the cost of implementing a fix, but I am not aware of anyone quantifying the total cost to a company in lost sales, company image, delayed purchases, etc.</p>
<p>Pipe up if you know better.</p>
<p>AllanC</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Coon</title>
		<link>http://www.dexodesign.com/2007/11/30/fixing-bugs-is-not-equivalent-to-fixing-design/#comment-71</link>
		<dc:creator>Mike Coon</dc:creator>
		<pubDate>Sat, 01 Dec 2007 00:23:00 +0000</pubDate>
		<guid isPermaLink="false">http://blog.dexodesign.com/2007/11/fixing-bugs-is-not-equivalent-to-fixing-design/#comment-71</guid>
		<description>You make a great point.  Even re-design in a major is risky.  I'm still hunting for stuff in Office 2007.&lt;br/&gt;&lt;br/&gt;Mike</description>
		<content:encoded><![CDATA[<p>You make a great point.  Even re-design in a major is risky.  I&#8217;m still hunting for stuff in Office 2007.</p>
<p>Mike</p>
]]></content:encoded>
	</item>
</channel>
</rss>
