<?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: Manage complexity like debt</title>
	<atom:link href="http://www.headwaysoftware.com/blog/2006/09/manage-complexity-like-debt/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.headwaysoftware.com/blog/2006/09/manage-complexity-like-debt/</link>
	<description></description>
	<lastBuildDate>Fri, 23 Dec 2011 12:59:15 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Haacked</title>
		<link>http://www.headwaysoftware.com/blog/2006/09/manage-complexity-like-debt/comment-page-1/#comment-26</link>
		<dc:creator>Haacked</dc:creator>
		<pubDate>Tue, 13 Mar 2007 22:45:50 +0000</pubDate>
		<guid isPermaLink="false">http://headway.structure101.com/blog/2006/09/manage-complexity-like-debt/#comment-26</guid>
		<description>&lt;p&gt;I&#039;ve heard this called &quot;Design Debt&quot; which is pretty much the same thing. &lt;/p&gt;

&lt;p&gt;I wrote up an example here: &lt;a href=&quot;http://haacked.com/archive/2005/09/24/GoingIntoDesignDebt.aspx&quot; rel=&quot;nofollow&quot;&gt;http://haacked.com/archive/2005/09/24/GoingIntoDesignDebt.aspx&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Joshua Kerievsky has some great illustrations of this in practice in the book &quot;Refactoring to Patterns&quot;.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>I&#8217;ve heard this called &#8220;Design Debt&#8221; which is pretty much the same thing. </p>
<p>I wrote up an example here: <a href="http://haacked.com/archive/2005/09/24/GoingIntoDesignDebt.aspx" rel="nofollow">http://haacked.com/archive/2005/09/24/GoingIntoDesignDebt.aspx</a></p>
<p>Joshua Kerievsky has some great illustrations of this in practice in the book &#8220;Refactoring to Patterns&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Frank Kelly</title>
		<link>http://www.headwaysoftware.com/blog/2006/09/manage-complexity-like-debt/comment-page-1/#comment-25</link>
		<dc:creator>Frank Kelly</dc:creator>
		<pubDate>Sun, 22 Oct 2006 21:41:58 +0000</pubDate>
		<guid isPermaLink="false">http://headway.structure101.com/blog/2006/09/manage-complexity-like-debt/#comment-25</guid>
		<description>&lt;p&gt;Hi Chris,  &lt;/p&gt;

&lt;p&gt;I agree that the &quot;debt&quot; terminiology is very useful in Software Engineering as a whole - where decisions (or lack thereof) come back later (with avengence) if not addressed.&lt;/p&gt;

&lt;p&gt;I&#039;ve blogged a little about this earlier this year - more focused on key design decisions and project planning.&lt;br /&gt;
&lt;a href=&quot;http://softarc.blogspot.com/2006/05/design-debt.html&quot; rel=&quot;nofollow&quot;&gt;http://softarc.blogspot.com/2006/05/design-debt.html&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Best,&lt;/p&gt;

&lt;p&gt;-Frank&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Hi Chris,  </p>
<p>I agree that the &#8220;debt&#8221; terminiology is very useful in Software Engineering as a whole &#8211; where decisions (or lack thereof) come back later (with avengence) if not addressed.</p>
<p>I&#8217;ve blogged a little about this earlier this year &#8211; more focused on key design decisions and project planning.<br />
<a href="http://softarc.blogspot.com/2006/05/design-debt.html" rel="nofollow">http://softarc.blogspot.com/2006/05/design-debt.html</a></p>
<p>Best,</p>
<p>-Frank</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paddy</title>
		<link>http://www.headwaysoftware.com/blog/2006/09/manage-complexity-like-debt/comment-page-1/#comment-24</link>
		<dc:creator>Paddy</dc:creator>
		<pubDate>Thu, 07 Sep 2006 11:13:17 +0000</pubDate>
		<guid isPermaLink="false">http://headway.structure101.com/blog/2006/09/manage-complexity-like-debt/#comment-24</guid>
		<description>&lt;p&gt;We have been using the term &quot;technical debt&quot; in our agile projects for a while now. Its a really useful metaphor for people close to the code. The problem is that unless you have a way to quantify it it remains abstract and intangible at a management level. What I like about Structure101 is that it gives me a means to quantify and communicate technical debt to people outside the development team.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>We have been using the term &#8220;technical debt&#8221; in our agile projects for a while now. Its a really useful metaphor for people close to the code. The problem is that unless you have a way to quantify it it remains abstract and intangible at a management level. What I like about Structure101 is that it gives me a means to quantify and communicate technical debt to people outside the development team.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

