<?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: IT Utopia!</title>
	<atom:link href="http://www.techdarkside.com/it-utopia/feed" rel="self" type="application/rss+xml" />
	<link>http://www.techdarkside.com/it-utopia</link>
	<description>Struggles of a Self-Taught Coder</description>
	<lastBuildDate>Tue, 07 Feb 2012 02:07:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: sozdanie saytov</title>
		<link>http://www.techdarkside.com/it-utopia/comment-page-1#comment-17282</link>
		<dc:creator>sozdanie saytov</dc:creator>
		<pubDate>Fri, 06 Aug 2010 15:14:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.techdarkside.com/?p=108#comment-17282</guid>
		<description>Nice post &quot;It Utopia&quot; !!! Tnks.</description>
		<content:encoded><![CDATA[<p>Nice post &#8220;It Utopia&#8221; !!! Tnks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: educational blog</title>
		<link>http://www.techdarkside.com/it-utopia/comment-page-1#comment-17064</link>
		<dc:creator>educational blog</dc:creator>
		<pubDate>Wed, 26 May 2010 08:42:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.techdarkside.com/?p=108#comment-17064</guid>
		<description>Very happy to read about IT Utopia! </description>
		<content:encoded><![CDATA[<p>Very happy to read about IT Utopia!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Allen</title>
		<link>http://www.techdarkside.com/it-utopia/comment-page-1#comment-11010</link>
		<dc:creator>Allen</dc:creator>
		<pubDate>Thu, 17 May 2007 19:26:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.techdarkside.com/?p=108#comment-11010</guid>
		<description>&quot;Weeks of coding can save you hours of planning&quot;
- Seen in a managers office at LM


Shhhhh... critical meeting in progress

of course then there is the other side...

&quot;Any problem can be made unsolvable
if enough meetings are held to discuss it.&quot;
 - Don Guinn</description>
		<content:encoded><![CDATA[<p>&#8220;Weeks of coding can save you hours of planning&#8221;<br />
- Seen in a managers office at LM</p>
<p>Shhhhh&#8230; critical meeting in progress</p>
<p>of course then there is the other side&#8230;</p>
<p>&#8220;Any problem can be made unsolvable<br />
if enough meetings are held to discuss it.&#8221;<br />
 &#8211; Don Guinn</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wayne M.</title>
		<link>http://www.techdarkside.com/it-utopia/comment-page-1#comment-10667</link>
		<dc:creator>Wayne M.</dc:creator>
		<pubDate>Mon, 14 May 2007 19:34:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.techdarkside.com/?p=108#comment-10667</guid>
		<description>This reminds me of many of the software development procedures I&#039;ve seen.  The common thread?  They all had a clause that exempted us from paperwork for &quot;emergency&quot; issues.  In other words, we had to follow the processes except when the issue was really, really important.  Too bad the rest of our work was not considered important.

P.S. Grammar Nazi Note: I believe you meant &quot;prescribe&quot; not &quot;proscribe.&quot;</description>
		<content:encoded><![CDATA[<p>This reminds me of many of the software development procedures I&#8217;ve seen.  The common thread?  They all had a clause that exempted us from paperwork for &#8220;emergency&#8221; issues.  In other words, we had to follow the processes except when the issue was really, really important.  Too bad the rest of our work was not considered important.</p>
<p>P.S. Grammar Nazi Note: I believe you meant &#8220;prescribe&#8221; not &#8220;proscribe.&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Drew Kime</title>
		<link>http://www.techdarkside.com/it-utopia/comment-page-1#comment-10647</link>
		<dc:creator>Drew Kime</dc:creator>
		<pubDate>Mon, 14 May 2007 16:14:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.techdarkside.com/?p=108#comment-10647</guid>
		<description>There are a couple of reasons this style isn&#039;t typical of IT projects. First is that production support is completely different from most project work in one very important way: the problem is well defined. Something worked on Monday, it doesn&#039;t work on Tuesday. Make it work just like Monday again.

The second reason is the staffing. For something with six-figure impact per hour you don&#039;t want an architect with an impressive resume, dozens of certifications, and decades of experience with your primary programming language. You want Bob, the guy who wrote the system from scratch, and demands $1k per hour with a four-hour minimum.

There are two reasons expert teams get away with less formal process than is typical, but I can only prove one of them. The official answer that business sponsors tell themselves is that the experts have worked &quot;the methodology&quot; for so long that they can follow the same procedures without exhaustively documenting all the steps. And there is some truth to that.

But I suspect the larger reason is that experts get the work done so much faster there just isn&#039;t enough time for documentation to build up.

The best athletes make things look easy that most people could not even do. The best IT people do the same thing. The management challenge is to recognize the difference between a project that went smoothly because it *was* easy, and one that went smoothly because the team made it *look* easy.</description>
		<content:encoded><![CDATA[<p>There are a couple of reasons this style isn&#8217;t typical of IT projects. First is that production support is completely different from most project work in one very important way: the problem is well defined. Something worked on Monday, it doesn&#8217;t work on Tuesday. Make it work just like Monday again.</p>
<p>The second reason is the staffing. For something with six-figure impact per hour you don&#8217;t want an architect with an impressive resume, dozens of certifications, and decades of experience with your primary programming language. You want Bob, the guy who wrote the system from scratch, and demands $1k per hour with a four-hour minimum.</p>
<p>There are two reasons expert teams get away with less formal process than is typical, but I can only prove one of them. The official answer that business sponsors tell themselves is that the experts have worked &#8220;the methodology&#8221; for so long that they can follow the same procedures without exhaustively documenting all the steps. And there is some truth to that.</p>
<p>But I suspect the larger reason is that experts get the work done so much faster there just isn&#8217;t enough time for documentation to build up.</p>
<p>The best athletes make things look easy that most people could not even do. The best IT people do the same thing. The management challenge is to recognize the difference between a project that went smoothly because it *was* easy, and one that went smoothly because the team made it *look* easy.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

