<?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: Technology Debt?  Don&#8217;t bet on it.</title>
	<atom:link href="http://reliable.esymmetrix.com/development/technology-debt-dont-bet-on-it/feed" rel="self" type="application/rss+xml" />
	<link>http://reliable.esymmetrix.com/development/technology-debt-dont-bet-on-it</link>
	<description>People, Processes, Hardware and Software that deliver results every time, every where.</description>
	<lastBuildDate>Wed, 06 Oct 2010 18:58:50 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2</generator>
	<item>
		<title>By: David</title>
		<link>http://reliable.esymmetrix.com/development/technology-debt-dont-bet-on-it/comment-page-1#comment-1048</link>
		<dc:creator>David</dc:creator>
		<pubDate>Sat, 21 Nov 2009 22:23:31 +0000</pubDate>
		<guid isPermaLink="false">http://kendall.srellim.org/?p=43#comment-1048</guid>
		<description>Technology debt is real - and yes it has to be paid back.  The challenge is &#039;how can the industry standardize or formulate a measure of Technology debt.
Theoretically &#039;the perfect system&#039; can be built eventually.  The perfect system never breaks and provides 100% business value 24/7.
All prior generation systems attempt to meet the perfect system standard, trade offs define the actual system.  Ergo, the difference between the perfect system and the delivered system(s) is the Debt.
Technology Debt encompasses the cost to the business, impacting new systems as well as the operational costs for existing systems.
The future of Enterprise Architecture is now?</description>
		<content:encoded><![CDATA[<p>Technology debt is real &#8211; and yes it has to be paid back.  The challenge is &#8216;how can the industry standardize or formulate a measure of Technology debt.<br />
Theoretically &#8216;the perfect system&#8217; can be built eventually.  The perfect system never breaks and provides 100% business value 24/7.<br />
All prior generation systems attempt to meet the perfect system standard, trade offs define the actual system.  Ergo, the difference between the perfect system and the delivered system(s) is the Debt.<br />
Technology Debt encompasses the cost to the business, impacting new systems as well as the operational costs for existing systems.<br />
The future of Enterprise Architecture is now?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ben rady</title>
		<link>http://reliable.esymmetrix.com/development/technology-debt-dont-bet-on-it/comment-page-1#comment-473</link>
		<dc:creator>ben rady</dc:creator>
		<pubDate>Tue, 19 Aug 2008 05:30:56 +0000</pubDate>
		<guid isPermaLink="false">http://kendall.srellim.org/?p=43#comment-473</guid>
		<description>Technical debt is not related to functionality (at least, not directly). I think the page on the C2 wiki describes it best (http://c2.com/cgi/wiki?TechnicalDebt). The authentication example you describe is clearly related to end-user value. 

I think what you&#039;re talking about is a violation of YAGNI (You Aren&#039;t Going to Need It). That is, building features that you don&#039;t need because you _might_ need them one day.

Reducing technical debt is all about keeping the code pliable so that when you need to switch from ADFS to a more general mechanism, the additional cost is minimal. 

I do agree, however, that the technical debt metaphor is often misused; Both by people who don&#039;t understand it, and by those seeking goals other than delivering valuable software.</description>
		<content:encoded><![CDATA[<p>Technical debt is not related to functionality (at least, not directly). I think the page on the C2 wiki describes it best (<a href="http://c2.com/cgi/wiki?TechnicalDebt" rel="nofollow">http://c2.com/cgi/wiki?TechnicalDebt</a>). The authentication example you describe is clearly related to end-user value. </p>
<p>I think what you&#8217;re talking about is a violation of YAGNI (You Aren&#8217;t Going to Need It). That is, building features that you don&#8217;t need because you _might_ need them one day.</p>
<p>Reducing technical debt is all about keeping the code pliable so that when you need to switch from ADFS to a more general mechanism, the additional cost is minimal. </p>
<p>I do agree, however, that the technical debt metaphor is often misused; Both by people who don&#8217;t understand it, and by those seeking goals other than delivering valuable software.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Xuarlapan</title>
		<link>http://reliable.esymmetrix.com/development/technology-debt-dont-bet-on-it/comment-page-1#comment-463</link>
		<dc:creator>Xuarlapan</dc:creator>
		<pubDate>Mon, 04 Aug 2008 21:16:27 +0000</pubDate>
		<guid isPermaLink="false">http://kendall.srellim.org/?p=43#comment-463</guid>
		<description>Nice post.  I use technology debt differently.  You&#039;ve used it to describe features (ie SAML) which were not built in to your system.  Real tech debt never has to do with features.

Tech dept occurs when you DO build things that USE some particular infrastructure, library, platform, etc and thereby pour concrete over it.

Now &quot;we can&#039;t build this feature because&quot; xyz-platform.net.lib.jar, which we have used all over the place, doesn&#039;t support it.  So we&#039;d need to re-write everything.&quot;

This is the part where you have to &quot;pay it back&quot;. Like all debt this is not in itself bad.

So I think the metaphor is OK, but your core message about clear communication and keeping things simple is spot on.

Cheers
X</description>
		<content:encoded><![CDATA[<p>Nice post.  I use technology debt differently.  You&#8217;ve used it to describe features (ie SAML) which were not built in to your system.  Real tech debt never has to do with features.</p>
<p>Tech dept occurs when you DO build things that USE some particular infrastructure, library, platform, etc and thereby pour concrete over it.</p>
<p>Now &#8220;we can&#8217;t build this feature because&#8221; xyz-platform.net.lib.jar, which we have used all over the place, doesn&#8217;t support it.  So we&#8217;d need to re-write everything.&#8221;</p>
<p>This is the part where you have to &#8220;pay it back&#8221;. Like all debt this is not in itself bad.</p>
<p>So I think the metaphor is OK, but your core message about clear communication and keeping things simple is spot on.</p>
<p>Cheers<br />
X</p>
]]></content:encoded>
	</item>
</channel>
</rss>

