<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: On dev software upgrades&#8211;when, why, how?</title>
	<atom:link href="http://blog.criticalresults.com/2009/11/11/on-dev-software-upgrades-when-why-how/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.criticalresults.com/2009/11/11/on-dev-software-upgrades-when-why-how/</link>
	<description>get software done faster, sharpen your team, gain balance and control... and make your project NOT SUCK</description>
	<lastBuildDate>Tue, 07 Jun 2011 02:37:40 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Mark W. Schumann</title>
		<link>http://blog.criticalresults.com/2009/11/11/on-dev-software-upgrades-when-why-how/#comment-95</link>
		<dc:creator><![CDATA[Mark W. Schumann]]></dc:creator>
		<pubDate>Thu, 12 Nov 2009 21:59:54 +0000</pubDate>
		<guid isPermaLink="false">http://blog.criticalresults.com/?p=52#comment-95</guid>
		<description><![CDATA[Scale makes a huge difference in how you approach these things. Upgrading a dev tool when you&#039;re a solo developer handling a few active projects with maybe a dozen or so in slow-maintenance mode is one thing. Tracking an enterprise-wide single signon? Wow. Totally not the same. It must be hard to get the corporate-level buy-in that you allude to, even though from the sound of it the upgrades are &lt;em&gt;absolutely essential&lt;/em&gt;, not a nice-to-have thing.

I am loving your &quot;root cause&quot; series, and the name &quot;MidWest IT Survival&quot; has just the right noir connotations.

Thanks for your comment, John, and for your contribution to the local tech blog scene.]]></description>
		<content:encoded><![CDATA[<p>Scale makes a huge difference in how you approach these things. Upgrading a dev tool when you&#8217;re a solo developer handling a few active projects with maybe a dozen or so in slow-maintenance mode is one thing. Tracking an enterprise-wide single signon? Wow. Totally not the same. It must be hard to get the corporate-level buy-in that you allude to, even though from the sound of it the upgrades are <em>absolutely essential</em>, not a nice-to-have thing.</p>
<p>I am loving your &#8220;root cause&#8221; series, and the name &#8220;MidWest IT Survival&#8221; has just the right noir connotations.</p>
<p>Thanks for your comment, John, and for your contribution to the local tech blog scene.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jfbauer</title>
		<link>http://blog.criticalresults.com/2009/11/11/on-dev-software-upgrades-when-why-how/#comment-94</link>
		<dc:creator><![CDATA[jfbauer]]></dc:creator>
		<pubDate>Thu, 12 Nov 2009 20:01:15 +0000</pubDate>
		<guid isPermaLink="false">http://blog.criticalresults.com/?p=52#comment-94</guid>
		<description><![CDATA[In my recent past at a larger IT organization, upgrades were indeed projects unto themselves.  Prior to my leaving, as soon as you completed one you immediately started a new one because the start to finish was about 1.5 years and growing.  That may give you some sense of size and scale of the technology.  The next trick is determining how to get those dull and boring to the business project prioritized high enough to make traction.  Luckily, the system I referred two was a customer facing SSO solution that needed to grow and scale ahead of the user base.  If it failed, all the products behind it failed.  So, upgrading to keep pace with new version performance enhancements was critical.  You could only tune the current version to a point and then the new version re-architected some component allow my throughput and thus upgrading was needed otherwise there really were no alternatives.

Some thoughts I&#039;ve collected similar on my blog: http://bit.ly/Ya8TQ]]></description>
		<content:encoded><![CDATA[<p>In my recent past at a larger IT organization, upgrades were indeed projects unto themselves.  Prior to my leaving, as soon as you completed one you immediately started a new one because the start to finish was about 1.5 years and growing.  That may give you some sense of size and scale of the technology.  The next trick is determining how to get those dull and boring to the business project prioritized high enough to make traction.  Luckily, the system I referred two was a customer facing SSO solution that needed to grow and scale ahead of the user base.  If it failed, all the products behind it failed.  So, upgrading to keep pace with new version performance enhancements was critical.  You could only tune the current version to a point and then the new version re-architected some component allow my throughput and thus upgrading was needed otherwise there really were no alternatives.</p>
<p>Some thoughts I&#8217;ve collected similar on my blog: <a href="http://bit.ly/Ya8TQ" rel="nofollow">http://bit.ly/Ya8TQ</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tweets that mention On dev software upgrades–when, why, how? « Critical Results -- Topsy.com</title>
		<link>http://blog.criticalresults.com/2009/11/11/on-dev-software-upgrades-when-why-how/#comment-93</link>
		<dc:creator><![CDATA[Tweets that mention On dev software upgrades–when, why, how? « Critical Results -- Topsy.com]]></dc:creator>
		<pubDate>Thu, 12 Nov 2009 01:50:16 +0000</pubDate>
		<guid isPermaLink="false">http://blog.criticalresults.com/?p=52#comment-93</guid>
		<description><![CDATA[[...] This post was mentioned on Twitter by Mark W. Schumann, Mark W. Schumann. Mark W. Schumann said: How often do you upgrade dev software? I&#039;m #agile about that, how about you? New blog post: http://bit.ly/2VTQbQ [...]]]></description>
		<content:encoded><![CDATA[<p>[...] This post was mentioned on Twitter by Mark W. Schumann, Mark W. Schumann. Mark W. Schumann said: How often do you upgrade dev software? I&#39;m #agile about that, how about you? New blog post: <a href="http://bit.ly/2VTQbQ" rel="nofollow">http://bit.ly/2VTQbQ</a> [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

