<?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: Ethics In Software Development: Pragmatism Over Dogmatism</title>
	<atom:link href="http://davybrion.com/blog/2009/01/ethics-in-software-development-pragmatism-over-dogmatism/feed/" rel="self" type="application/rss+xml" />
	<link>http://davybrion.com/blog/2009/01/ethics-in-software-development-pragmatism-over-dogmatism/</link>
	<description>Trying to walk that thin line between intelligence and ignorance</description>
	<lastBuildDate>Mon, 15 Mar 2010 08:03:58 +0100</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Ibrahim Levent</title>
		<link>http://davybrion.com/blog/2009/01/ethics-in-software-development-pragmatism-over-dogmatism/comment-page-1/#comment-7652</link>
		<dc:creator>Ibrahim Levent</dc:creator>
		<pubDate>Wed, 14 Jan 2009 16:21:41 +0000</pubDate>
		<guid isPermaLink="false">http://davybrion.com/blog/?p=845#comment-7652</guid>
		<description>Schedule pressure may sometimes force us to make some &quot;Quick-dirty fixes&quot;. When I do this, I just mark the code for later correction(With a tag like &quot;REMIND: Fix better&quot;). Later I search these marks and try to fix in a better way. Some refactorings(Large code changes) may also eliminate these qirty conditions. It is much more probable that we find a better way if we give time for it. Later clean fix may be better than initial clean fix with the cost of remembering problem context again.</description>
		<content:encoded><![CDATA[<p>Schedule pressure may sometimes force us to make some &#8220;Quick-dirty fixes&#8221;. When I do this, I just mark the code for later correction(With a tag like &#8220;REMIND: Fix better&#8221;). Later I search these marks and try to fix in a better way. Some refactorings(Large code changes) may also eliminate these qirty conditions. It is much more probable that we find a better way if we give time for it. Later clean fix may be better than initial clean fix with the cost of remembering problem context again.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: efdee</title>
		<link>http://davybrion.com/blog/2009/01/ethics-in-software-development-pragmatism-over-dogmatism/comment-page-1/#comment-7622</link>
		<dc:creator>efdee</dc:creator>
		<pubDate>Tue, 13 Jan 2009 13:51:16 +0000</pubDate>
		<guid isPermaLink="false">http://davybrion.com/blog/?p=845#comment-7622</guid>
		<description>I think the problem is that ultimately it is the developer who has to make the call as to whether or not to implement a clean fix or a quick fix, and whether or not he makes the right choice boils down to how skilled he is. I definitely agree with the example you give and I assume you are able to make the right choices because you have a solid education in software development.

Maybe I just don&#039;t like the word &#039;pragmatism&#039; because for too much people it is just an excuse to go the quick fix route.</description>
		<content:encoded><![CDATA[<p>I think the problem is that ultimately it is the developer who has to make the call as to whether or not to implement a clean fix or a quick fix, and whether or not he makes the right choice boils down to how skilled he is. I definitely agree with the example you give and I assume you are able to make the right choices because you have a solid education in software development.</p>
<p>Maybe I just don&#8217;t like the word &#8216;pragmatism&#8217; because for too much people it is just an excuse to go the quick fix route.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
