<?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: Duke Nukem Forever &amp; Reworking code</title>
	<atom:link href="http://www.markhneedham.com/blog/2009/12/23/duke-nukem-forever-reworking-code/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.markhneedham.com/blog/2009/12/23/duke-nukem-forever-reworking-code/</link>
	<description>Thoughts on Software Development</description>
	<lastBuildDate>Sat, 11 Feb 2012 23:17:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: DCam</title>
		<link>http://www.markhneedham.com/blog/2009/12/23/duke-nukem-forever-reworking-code/comment-page-1/#comment-29479</link>
		<dc:creator>DCam</dc:creator>
		<pubDate>Fri, 01 Jan 2010 23:45:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.markhneedham.com/blog/?p=1966#comment-29479</guid>
		<description>It seems sometimes it is worth thinking of the developers as one more set of &quot;users&quot; of the code being written. If they are, then some of their requirements may be around prettiness of the code, speed of the build and other &#039;technical&#039; concerns. These requirements need to be balanced against other requirements on the code base.

They are unique among requirements though, because the people who want them—the developers—are also the people who can make them happen. We need to be especially careful as developers that we are not subverting the whole prioritisation process to meet the requirements most valuable to us, instead of those most valuable to the project or business as a whole.</description>
		<content:encoded><![CDATA[<p>It seems sometimes it is worth thinking of the developers as one more set of &#8220;users&#8221; of the code being written. If they are, then some of their requirements may be around prettiness of the code, speed of the build and other &#8216;technical&#8217; concerns. These requirements need to be balanced against other requirements on the code base.</p>
<p>They are unique among requirements though, because the people who want them—the developers—are also the people who can make them happen. We need to be especially careful as developers that we are not subverting the whole prioritisation process to meet the requirements most valuable to us, instead of those most valuable to the project or business as a whole.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tweets that mention Duke Nukem Forever &#38; Reworking code at Mark Needham -- Topsy.com</title>
		<link>http://www.markhneedham.com/blog/2009/12/23/duke-nukem-forever-reworking-code/comment-page-1/#comment-28818</link>
		<dc:creator>Tweets that mention Duke Nukem Forever &#38; Reworking code at Mark Needham -- Topsy.com</dc:creator>
		<pubDate>Tue, 22 Dec 2009 23:13:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.markhneedham.com/blog/?p=1966#comment-28818</guid>
		<description>[...] This post was mentioned on Twitter by Anna Nachesa, planettw. planettw said: Mark Needham: Duke Nukem Forever &amp; Reworking code: Cosmin Stejerean linked to a really interesting article on wired... http://bit.ly/78bGbN [...]</description>
		<content:encoded><![CDATA[<p>[...] This post was mentioned on Twitter by Anna Nachesa, planettw. planettw said: Mark Needham: Duke Nukem Forever &amp; Reworking code: Cosmin Stejerean linked to a really interesting article on wired&#8230; <a href="http://bit.ly/78bGbN" rel="nofollow">http://bit.ly/78bGbN</a> [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Melinn</title>
		<link>http://www.markhneedham.com/blog/2009/12/23/duke-nukem-forever-reworking-code/comment-page-1/#comment-28817</link>
		<dc:creator>Chris Melinn</dc:creator>
		<pubDate>Tue, 22 Dec 2009 22:50:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.markhneedham.com/blog/?p=1966#comment-28817</guid>
		<description>If you want to focus on code that you&#039;re working on, and, if you can assume your pain points are untested (or poorly tested) code, then this post by Patrick Smacchia describes a great idea how to use NDepend to ensure new/refactored code is well covered by tests:

http://codebetter.com/blogs/patricksmacchia/archive/2008/07/10/are-you-sure-added-and-refactored-code-is-covered-by-tests.aspx

I think this idea is especially useful if you have a &quot;legacy&quot; application that wasn&#039;t done with TDD or other unit tests, but you want to begin a more TDD-style approach from that point on.</description>
		<content:encoded><![CDATA[<p>If you want to focus on code that you&#8217;re working on, and, if you can assume your pain points are untested (or poorly tested) code, then this post by Patrick Smacchia describes a great idea how to use NDepend to ensure new/refactored code is well covered by tests:</p>
<p><a href="http://codebetter.com/blogs/patricksmacchia/archive/2008/07/10/are-you-sure-added-and-refactored-code-is-covered-by-tests.aspx" rel="nofollow">http://codebetter.com/blogs/patricksmacchia/archive/2008/07/10/are-you-sure-added-and-refactored-code-is-covered-by-tests.aspx</a></p>
<p>I think this idea is especially useful if you have a &#8220;legacy&#8221; application that wasn&#8217;t done with TDD or other unit tests, but you want to begin a more TDD-style approach from that point on.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

