<?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:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
xmlns:rawvoice="http://www.rawvoice.com/rawvoiceRssModule/"
	>
<channel>
	<title>Comments on: Attacking Technical Debt</title>
	<atom:link href="http://www.clarrus.com/2009/08/attacking-technical-debt/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.clarrus.com/2009/08/attacking-technical-debt/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=attacking-technical-debt</link>
	<description>The Results are in the Team</description>
	<lastBuildDate>Mon, 16 Jan 2012 23:11:09 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Jim Brosseau</title>
		<link>http://www.clarrus.com/2009/08/attacking-technical-debt/comment-page-1/#comment-19</link>
		<dc:creator>Jim Brosseau</dc:creator>
		<pubDate>Wed, 26 Aug 2009 21:00:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.clarrus.com/?p=1012#comment-19</guid>
		<description>...the responsibility is on testing &lt;em&gt;and planning&lt;/em&gt;. When we were building an ATC system iteratively, there were times when we replaced massive chunks of the underlying architecture. Each one of these was a project on its own, with the incorporation into the layers of the architecture planned out and validated at each stage before moving on, until it finally was &#039;just a part of the new mainstream&#039;.

For refactoring to work, there can&#039;t be any &#039;I hope things don&#039;t blow up when I push this button&#039; moments...</description>
		<content:encoded><![CDATA[<p>&#8230;the responsibility is on testing <em>and planning</em>. When we were building an ATC system iteratively, there were times when we replaced massive chunks of the underlying architecture. Each one of these was a project on its own, with the incorporation into the layers of the architecture planned out and validated at each stage before moving on, until it finally was &#8216;just a part of the new mainstream&#8217;.</p>
<p>For refactoring to work, there can&#8217;t be any &#8216;I hope things don&#8217;t blow up when I push this button&#8217; moments&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Geoff</title>
		<link>http://www.clarrus.com/2009/08/attacking-technical-debt/comment-page-1/#comment-18</link>
		<dc:creator>Geoff</dc:creator>
		<pubDate>Wed, 26 Aug 2009 16:26:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.clarrus.com/?p=1012#comment-18</guid>
		<description>Jim, when this refactoring works it is awesome but changing anything that is currently working is a very nervous proposition indeed. The responsibility being put on the testing activity is immense. All I can think of is that I would have loved to have been in the boardroom at Apple for the discussions on business ROI for all of this activity.

Refactoring scares the crap out of me.</description>
		<content:encoded><![CDATA[<p>Jim, when this refactoring works it is awesome but changing anything that is currently working is a very nervous proposition indeed. The responsibility being put on the testing activity is immense. All I can think of is that I would have loved to have been in the boardroom at Apple for the discussions on business ROI for all of this activity.</p>
<p>Refactoring scares the crap out of me.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

