<?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: Why does Software Suck? Part II</title>
	<atom:link href="http://davidinman.net/2010/01/10/why-does-software-suck-part-ii/feed/" rel="self" type="application/rss+xml" />
	<link>http://davidinman.net/2010/01/10/why-does-software-suck-part-ii/</link>
	<description></description>
	<lastBuildDate>Mon, 09 Aug 2010 04:36:42 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: David</title>
		<link>http://davidinman.net/2010/01/10/why-does-software-suck-part-ii/comment-page-1/#comment-4222</link>
		<dc:creator>David</dc:creator>
		<pubDate>Mon, 18 Jan 2010 02:42:39 +0000</pubDate>
		<guid isPermaLink="false">http://davidinman.net/?p=386#comment-4222</guid>
		<description>Jarred:

I didn&#039;t make it explicit, but I meant to include &quot;all possibilities&quot; under point 1. Part of thinking like a human is imagining what the user will do (and amazingly few engineers do this, thus were born bad user interfaces - hello Photoshop!).

Yeah, I have a friend who works on drivers on he has definitely been in the &quot;we&#039;ll fix it in software&quot; end of the equation. Not a fun place to be from what I&#039;ve heard. Then you make a bug fixing the hardware bug and people exploit it and so now you have to reliably reproduce what was originally a bug which some programs now depend on. Whoopee!</description>
		<content:encoded><![CDATA[<p>Jarred:</p>
<p>I didn&#8217;t make it explicit, but I meant to include &#8220;all possibilities&#8221; under point 1. Part of thinking like a human is imagining what the user will do (and amazingly few engineers do this, thus were born bad user interfaces &#8211; hello Photoshop!).</p>
<p>Yeah, I have a friend who works on drivers on he has definitely been in the &#8220;we&#8217;ll fix it in software&#8221; end of the equation. Not a fun place to be from what I&#8217;ve heard. Then you make a bug fixing the hardware bug and people exploit it and so now you have to reliably reproduce what was originally a bug which some programs now depend on. Whoopee!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jarred</title>
		<link>http://davidinman.net/2010/01/10/why-does-software-suck-part-ii/comment-page-1/#comment-4174</link>
		<dc:creator>Jarred</dc:creator>
		<pubDate>Mon, 11 Jan 2010 02:15:24 +0000</pubDate>
		<guid isPermaLink="false">http://davidinman.net/?p=386#comment-4174</guid>
		<description>Under point 1, I&#039;d also add the point that you have to allow for every possibility, especially if your software interacts with an end user.  End users are notorious for doing things we don&#039;t expect them to do.  This means a good program needs to do error checking.  Similarly, hardware occasionally does something we don&#039;t expect, and software has to be able to handle the case where the printer suddenly quits responding to our print requests for twenty seconds or the SCSI drive aborts in the middle of reading our file.  Again, a good operating system handles a lot of this, but in some cases, the operating system may choose to handle it by telling an application, &quot;Sorry, something bad happened.  I was unable to do what you asked me to.&quot;

While we&#039;re talking about hardware, I&#039;ll also point out that the ephemeral nature of software also means that managers (and hardware engineers) often expect software to make up for deficiencies or erroneous behavior in hardware.  As someone who works in an embedded environment most of the time, I can&#039;t tell you the number of times I&#039;ve heard the phrase, &quot;fix it in software.&quot;  This adds complexity -- and therefore potential problems -- to software.</description>
		<content:encoded><![CDATA[<p>Under point 1, I&#8217;d also add the point that you have to allow for every possibility, especially if your software interacts with an end user.  End users are notorious for doing things we don&#8217;t expect them to do.  This means a good program needs to do error checking.  Similarly, hardware occasionally does something we don&#8217;t expect, and software has to be able to handle the case where the printer suddenly quits responding to our print requests for twenty seconds or the SCSI drive aborts in the middle of reading our file.  Again, a good operating system handles a lot of this, but in some cases, the operating system may choose to handle it by telling an application, &#8220;Sorry, something bad happened.  I was unable to do what you asked me to.&#8221;</p>
<p>While we&#8217;re talking about hardware, I&#8217;ll also point out that the ephemeral nature of software also means that managers (and hardware engineers) often expect software to make up for deficiencies or erroneous behavior in hardware.  As someone who works in an embedded environment most of the time, I can&#8217;t tell you the number of times I&#8217;ve heard the phrase, &#8220;fix it in software.&#8221;  This adds complexity &#8212; and therefore potential problems &#8212; to software.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joseph</title>
		<link>http://davidinman.net/2010/01/10/why-does-software-suck-part-ii/comment-page-1/#comment-4172</link>
		<dc:creator>Joseph</dc:creator>
		<pubDate>Mon, 11 Jan 2010 01:42:02 +0000</pubDate>
		<guid isPermaLink="false">http://davidinman.net/?p=386#comment-4172</guid>
		<description>This was not too ranty!  I enjoyed it.  You&#039;ve inspired me to write about something I know about now.</description>
		<content:encoded><![CDATA[<p>This was not too ranty!  I enjoyed it.  You&#8217;ve inspired me to write about something I know about now.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
