<?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: A Productive Day</title> <atom:link href="http://www.symphonious.net/2007/02/15/a-productive-day/feed/" rel="self" type="application/rss+xml" /><link>http://www.symphonious.net/2007/02/15/a-productive-day/</link> <description>Living in a state of accord.</description> <lastBuildDate>Tue, 07 Feb 2012 01:07:58 +0000</lastBuildDate> <sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>1</sy:updateFrequency> <generator>http://wordpress.org/?v=3.3.1</generator> <item><title>By: Iain Robertson</title><link>http://www.symphonious.net/2007/02/15/a-productive-day/comment-page-1/#comment-59896</link> <dc:creator>Iain Robertson</dc:creator> <pubDate>Sun, 18 Feb 2007 06:02:36 +0000</pubDate> <guid
isPermaLink="false">http://www.symphonious.net/2007/02/15/a-productive-day/#comment-59896</guid> <description>Ah yes: metrics for metrics&#039; sake.  My employer is a big fan of Earned Value, and the only real way to make collective earned value grow is, generally speaking, to let the code base grow.  As it stands we&#039;re well over 100kSLOC1, and growing, for a product that could (largely) be replaced with COTS or Open Source product, or more precisely combinations thereof, if only we&#039;d &lt;i&gt;properly&lt;/i&gt; embrace &quot;acquire&quot; instead of &quot;build.&quot;
Management have been known to become positively ecstatic when, in the course of a few hours, junior developers write methods (yes, methods — not classes!) containing 1000 lines of non-comment code, and ask all sorts of Very Pointed Questions when said code gets refactored into something a little more efficient, partly because it looks like we&#039;ve gone backward, and partly because it&#039;s &quot;bad&quot; for the SLOC/hour metric. Perish the thought of redundant code ever being deleted!
Fortunately we have a few sensible team leads who act as a fantastic buffer, and who understand the pointlessness of such metrics.
1. Source Line(s) Of Code, or thousand Source Lines Of Code - more accurately, semicolons (it&#039;s a rough calculation of executable code, i.e. excludes comments and the like).  Utter garbage, of course, since several of our senior developers can write in fifty lines what the juniors will take five hundred to do.</description> <content:encoded><![CDATA[<p>Ah yes: metrics for metrics&#8217; sake.  My employer is a big fan of Earned Value, and the only real way to make collective earned value grow is, generally speaking, to let the code base grow.  As it stands we&#8217;re well over 100kSLOC1, and growing, for a product that could (largely) be replaced with COTS or Open Source product, or more precisely combinations thereof, if only we&#8217;d <i>properly</i> embrace &#8220;acquire&#8221; instead of &#8220;build.&#8221;</p><p>Management have been known to become positively ecstatic when, in the course of a few hours, junior developers write methods (yes, methods — not classes!) containing 1000 lines of non-comment code, and ask all sorts of Very Pointed Questions when said code gets refactored into something a little more efficient, partly because it looks like we&#8217;ve gone backward, and partly because it&#8217;s &#8220;bad&#8221; for the SLOC/hour metric. Perish the thought of redundant code ever being deleted!</p><p>Fortunately we have a few sensible team leads who act as a fantastic buffer, and who understand the pointlessness of such metrics.</p><p>1. Source Line(s) Of Code, or thousand Source Lines Of Code &#8211; more accurately, semicolons (it&#8217;s a rough calculation of executable code, i.e. excludes comments and the like).  Utter garbage, of course, since several of our senior developers can write in fifty lines what the juniors will take five hundred to do.</p> ]]></content:encoded> </item> </channel> </rss>
