<?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: Code Debt</title>
	<atom:link href="http://www.brainfuel.tv/code-debt/feed" rel="self" type="application/rss+xml" />
	<link>http://www.brainfuel.tv/code-debt</link>
	<description>Anything is possible... with brainfuel!</description>
	<lastBuildDate>Thu, 05 Jan 2012 20:48:07 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Henrik Sorensen</title>
		<link>http://www.brainfuel.tv/code-debt/comment-page-1#comment-612465</link>
		<dc:creator>Henrik Sorensen</dc:creator>
		<pubDate>Thu, 12 Jun 2008 07:31:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.brainfuel.tv/?p=1486#comment-612465</guid>
		<description>Nice! Here in Denmark there is a growing part of the programmers from the University with the idea that &quot;Code?!?! That comes from India!&quot;.. whereas I hold a B.Sc.E.E. and try and use my head when coding. 

I have a rule which has worked so far: &quot;Doubling the number of code lines will quadruple the chance of error&quot;. 

People ( most programmers I&#039;ve met at least ) don&#039;t use their head when coding - the use the rear end. E.g.: I used to work in a large, international company making Sound and Vibration Measurement systems. We did a new generation of systems and the guys who designed the data model LOVED themselves.. Sitting at a P4 2,4 GHz they made a HUGE, object oriented data model which took 10,000 code lines to set a single integer value?!?!? When running on a 398 MHz XScale this is not an option if it has to be &quot;realtime&quot;..  Finally, after 4 months of arguing with my boss 4 of us got to create a &quot;Performance Improval Team&quot;. 1 month later we had optimized the frame rate a factor x6, reduced the number of lines needed for setting the integer to only 100 ( including event handlers ) and the instrument actually worked now.. 

But complaining about managers&#039; decisions ( e.g. using .NET on the small platform or having Server guys design handheld software ) wasn&#039;t a great leap for my carreer.. Good thing that Denmark needs engineers. Got another job and a 30% raise.. 

Too much time is wasted on bad programming, lousy design and bad communication / management. And also ignorant marketing. Will this change? I doubt it..</description>
		<content:encoded><![CDATA[<p>Nice! Here in Denmark there is a growing part of the programmers from the University with the idea that &#8220;Code?!?! That comes from India!&#8221;.. whereas I hold a B.Sc.E.E. and try and use my head when coding. </p>
<p>I have a rule which has worked so far: &#8220;Doubling the number of code lines will quadruple the chance of error&#8221;. </p>
<p>People ( most programmers I&#8217;ve met at least ) don&#8217;t use their head when coding &#8211; the use the rear end. E.g.: I used to work in a large, international company making Sound and Vibration Measurement systems. We did a new generation of systems and the guys who designed the data model LOVED themselves.. Sitting at a P4 2,4 GHz they made a HUGE, object oriented data model which took 10,000 code lines to set a single integer value?!?!? When running on a 398 MHz XScale this is not an option if it has to be &#8220;realtime&#8221;..  Finally, after 4 months of arguing with my boss 4 of us got to create a &#8220;Performance Improval Team&#8221;. 1 month later we had optimized the frame rate a factor x6, reduced the number of lines needed for setting the integer to only 100 ( including event handlers ) and the instrument actually worked now.. </p>
<p>But complaining about managers&#8217; decisions ( e.g. using .NET on the small platform or having Server guys design handheld software ) wasn&#8217;t a great leap for my carreer.. Good thing that Denmark needs engineers. Got another job and a 30% raise.. </p>
<p>Too much time is wasted on bad programming, lousy design and bad communication / management. And also ignorant marketing. Will this change? I doubt it..</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Melbourne XP Enthusiasts Group (MXPEG) &#171; Alec the Geek</title>
		<link>http://www.brainfuel.tv/code-debt/comment-page-1#comment-136318</link>
		<dc:creator>Melbourne XP Enthusiasts Group (MXPEG) &#171; Alec the Geek</dc:creator>
		<pubDate>Tue, 10 Oct 2006 12:31:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.brainfuel.tv/?p=1486#comment-136318</guid>
		<description>[...] There was considerable discussion on how to plan Agile projects and deliverables with customers: in particular the issues of payment schedules for features (when to pay and how much);&#160; and how to address the code debt were of intrested me. [...]</description>
		<content:encoded><![CDATA[<p>[...] There was considerable discussion on how to plan Agile projects and deliverables with customers: in particular the issues of payment schedules for features (when to pay and how much);&nbsp; and how to address the code debt were of intrested me. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Tingom</title>
		<link>http://www.brainfuel.tv/code-debt/comment-page-1#comment-30037</link>
		<dc:creator>Chris Tingom</dc:creator>
		<pubDate>Tue, 04 Oct 2005 17:24:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.brainfuel.tv/?p=1486#comment-30037</guid>
		<description>Sean,
Very cool. Yeah, Grid7 sounds cool. Also you should check out RefreshPhoenix... there was a link to it in my post from Saturday night.
Chris</description>
		<content:encoded><![CDATA[<p>Sean,<br />
Very cool. Yeah, Grid7 sounds cool. Also you should check out RefreshPhoenix&#8230; there was a link to it in my post from Saturday night.<br />
Chris</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sean Tierney</title>
		<link>http://www.brainfuel.tv/code-debt/comment-page-1#comment-30014</link>
		<dc:creator>Sean Tierney</dc:creator>
		<pubDate>Tue, 04 Oct 2005 05:41:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.brainfuel.tv/?p=1486#comment-30014</guid>
		<description>Chris,
my buddy Jamon told me about your blog. I&#039;ve followed Kathy Sierra&#039;s (another fellow 9rules member) regularly and when I saw you were on 9rules, I figured it was worth a read.  

yea, let&#039;s definitely meet up sometime.  i&#039;ll drop you a line next grid7 meeting we have (grid7.biz) and do the same if you put together a bowling event or whatever.
good to meet you
Sean</description>
		<content:encoded><![CDATA[<p>Chris,<br />
my buddy Jamon told me about your blog. I&#8217;ve followed Kathy Sierra&#8217;s (another fellow 9rules member) regularly and when I saw you were on 9rules, I figured it was worth a read.  </p>
<p>yea, let&#8217;s definitely meet up sometime.  i&#8217;ll drop you a line next grid7 meeting we have (grid7.biz) and do the same if you put together a bowling event or whatever.<br />
good to meet you<br />
Sean</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Tingom</title>
		<link>http://www.brainfuel.tv/code-debt/comment-page-1#comment-29885</link>
		<dc:creator>Chris Tingom</dc:creator>
		<pubDate>Sat, 01 Oct 2005 00:11:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.brainfuel.tv/?p=1486#comment-29885</guid>
		<description>Hi Sean: A fellow Scottsdale resident! Wow, so how did you find BrainFuel?

Thanks for the feedback. I think you provide a great point... that a very well written application can be a blessing to update and maintain. It all comes down to who developed it and the great mystery... did they do a good job. Thanks for writing. 

We should do a BrainFuel get together some night with all of the Arizona people. Maybe bowling or something.</description>
		<content:encoded><![CDATA[<p>Hi Sean: A fellow Scottsdale resident! Wow, so how did you find BrainFuel?</p>
<p>Thanks for the feedback. I think you provide a great point&#8230; that a very well written application can be a blessing to update and maintain. It all comes down to who developed it and the great mystery&#8230; did they do a good job. Thanks for writing. </p>
<p>We should do a BrainFuel get together some night with all of the Arizona people. Maybe bowling or something.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sean Tierney</title>
		<link>http://www.brainfuel.tv/code-debt/comment-page-1#comment-29879</link>
		<dc:creator>Sean Tierney</dc:creator>
		<pubDate>Fri, 30 Sep 2005 20:46:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.brainfuel.tv/?p=1486#comment-29879</guid>
		<description>Chris,
nice post. I&#039;ve followed Jason&#039;s blog for about a year now, i use Backpack and I&#039;ve heard this podcast before. Code debt is a very real concept- he&#039;s spot on with his comparison to the concept of inertia in physics and the difficulty of changing direction when there is greater mass.  While a bloated feature-set undoubtedly makes for more mass and consequently trickier maintenance, I would argue that a bigger predictor is the way in which the app is architected.  I&#039;ve seen dense, feature-rich applications coded with good object-oriented principles that are a dream to maintain and extend and, conversely, I&#039;ve seen seemingly-simple apps hacked together with no adherence to a framework or good design principles and they are a nightmare to work with and maintain.  So while I think he has valid points and it&#039;s important to whittle down the features to the core essential ones, equally if not more important is the need to develop the app with an eye towards good OO principles and code reuse.

sean

ps. i&#039;m a fellow arizonan living in scottsdale, cheers.</description>
		<content:encoded><![CDATA[<p>Chris,<br />
nice post. I&#8217;ve followed Jason&#8217;s blog for about a year now, i use Backpack and I&#8217;ve heard this podcast before. Code debt is a very real concept- he&#8217;s spot on with his comparison to the concept of inertia in physics and the difficulty of changing direction when there is greater mass.  While a bloated feature-set undoubtedly makes for more mass and consequently trickier maintenance, I would argue that a bigger predictor is the way in which the app is architected.  I&#8217;ve seen dense, feature-rich applications coded with good object-oriented principles that are a dream to maintain and extend and, conversely, I&#8217;ve seen seemingly-simple apps hacked together with no adherence to a framework or good design principles and they are a nightmare to work with and maintain.  So while I think he has valid points and it&#8217;s important to whittle down the features to the core essential ones, equally if not more important is the need to develop the app with an eye towards good OO principles and code reuse.</p>
<p>sean</p>
<p>ps. i&#8217;m a fellow arizonan living in scottsdale, cheers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Tingom</title>
		<link>http://www.brainfuel.tv/code-debt/comment-page-1#comment-29804</link>
		<dc:creator>Chris Tingom</dc:creator>
		<pubDate>Fri, 30 Sep 2005 05:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.brainfuel.tv/?p=1486#comment-29804</guid>
		<description>Thanks for the great feedback everyone. The podcast just made me want to go out and create something and do it well.</description>
		<content:encoded><![CDATA[<p>Thanks for the great feedback everyone. The podcast just made me want to go out and create something and do it well.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ara Pehlivanian</title>
		<link>http://www.brainfuel.tv/code-debt/comment-page-1#comment-29777</link>
		<dc:creator>Ara Pehlivanian</dc:creator>
		<pubDate>Thu, 29 Sep 2005 18:53:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.brainfuel.tv/?p=1486#comment-29777</guid>
		<description>That&#039;s one of the reasons I got out of freelance work. The client kept coming back for upgrades and maintenance. The problem was, I hadn&#039;t clearly specified what was considered maintenance and what was part of the original contract. So I guess you could say that I blindly walked into code debt without even knowing it!</description>
		<content:encoded><![CDATA[<p>That&#8217;s one of the reasons I got out of freelance work. The client kept coming back for upgrades and maintenance. The problem was, I hadn&#8217;t clearly specified what was considered maintenance and what was part of the original contract. So I guess you could say that I blindly walked into code debt without even knowing it!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike P.</title>
		<link>http://www.brainfuel.tv/code-debt/comment-page-1#comment-29773</link>
		<dc:creator>Mike P.</dc:creator>
		<pubDate>Thu, 29 Sep 2005 16:51:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.brainfuel.tv/?p=1486#comment-29773</guid>
		<description>Yes and Yes.

Funny, I&#039;ve been stuck on the same idea, and the idea has been pouring through my head as I think about the basic functions of our cms...

A very useful podcast.</description>
		<content:encoded><![CDATA[<p>Yes and Yes.</p>
<p>Funny, I&#8217;ve been stuck on the same idea, and the idea has been pouring through my head as I think about the basic functions of our cms&#8230;</p>
<p>A very useful podcast.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sally Carson</title>
		<link>http://www.brainfuel.tv/code-debt/comment-page-1#comment-29767</link>
		<dc:creator>Sally Carson</dc:creator>
		<pubDate>Thu, 29 Sep 2005 16:15:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.brainfuel.tv/?p=1486#comment-29767</guid>
		<description>Great topic! I really enjoyed that podcast too. I guess I have a bit of a different spin on it. I&#039;m an in-house designer for a large e-commerce business. I&#039;m working for people that mostly don&#039;t know much about what I do. I&#039;m not creating software, but &quot;code debt&quot; seems to apply to web page development too.  

The emphasis with new projects is always on &quot;how fast can you get something out there?!&quot; with the promise that we&#039;ll have time to circle back later and clean it up, which never happens. What results is kludgy code that creates more work in the future for us that the managers aren&#039;t aware of or don&#039;t want us spending time on. 

There&#039;s really no reward for taking time to code something properly in the beginning in order to save yourself more work in the future. It makes for a very frustrating work environment. I use this analogy: imagine if your desk is really cluttered and disorganized but you were never allowed time to clean it up so that you could get some work done, you just keep piling folders and papers and burritos and coffee cups on top of it. That&#039;s our code, ha ha!</description>
		<content:encoded><![CDATA[<p>Great topic! I really enjoyed that podcast too. I guess I have a bit of a different spin on it. I&#8217;m an in-house designer for a large e-commerce business. I&#8217;m working for people that mostly don&#8217;t know much about what I do. I&#8217;m not creating software, but &#8220;code debt&#8221; seems to apply to web page development too.  </p>
<p>The emphasis with new projects is always on &#8220;how fast can you get something out there?!&#8221; with the promise that we&#8217;ll have time to circle back later and clean it up, which never happens. What results is kludgy code that creates more work in the future for us that the managers aren&#8217;t aware of or don&#8217;t want us spending time on. </p>
<p>There&#8217;s really no reward for taking time to code something properly in the beginning in order to save yourself more work in the future. It makes for a very frustrating work environment. I use this analogy: imagine if your desk is really cluttered and disorganized but you were never allowed time to clean it up so that you could get some work done, you just keep piling folders and papers and burritos and coffee cups on top of it. That&#8217;s our code, ha ha!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.209 seconds -->
<!-- Cached page served by WP-Cache -->

