<?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: Cool software design insight #1</title>
	<atom:link href="http://lemire.me/blog/archives/2008/07/30/cool-software-design-insight-1/feed/" rel="self" type="application/rss+xml" />
	<link>http://lemire.me/blog/archives/2008/07/30/cool-software-design-insight-1/</link>
	<description>Computer Scientist and Open Scholar: Databases, Information Retrieval, Business Intelligence.</description>
	<lastBuildDate>Wed, 23 May 2012 19:07:50 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: Daniel Haran</title>
		<link>http://lemire.me/blog/archives/2008/07/30/cool-software-design-insight-1/comment-page-1/#comment-50061</link>
		<dc:creator>Daniel Haran</dc:creator>
		<pubDate>Thu, 31 Jul 2008 03:30:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.daniel-lemire.com/blog/archives/2008/07/30/cool-software-design-insight-1/#comment-50061</guid>
		<description>aka YAGNI: http://en.wikipedia.org/wiki/YAGNI</description>
		<content:encoded><![CDATA[<p>aka YAGNI: <a href="http://en.wikipedia.org/wiki/YAGNI" rel="nofollow">http://en.wikipedia.org/wiki/YAGNI</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Reid</title>
		<link>http://lemire.me/blog/archives/2008/07/30/cool-software-design-insight-1/comment-page-1/#comment-50059</link>
		<dc:creator>Mark Reid</dc:creator>
		<pubDate>Wed, 30 Jul 2008 23:06:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.daniel-lemire.com/blog/archives/2008/07/30/cool-software-design-insight-1/#comment-50059</guid>
		<description>I also came to the same conclusion after working as a commercial programmer for a few years. When it comes to code &quot;less is more&quot;.

While it&#039;s not a solution for everything, one thing test driven design does well is make you focus on the features that are essential. The best way to avoid useless features is not write them in the first place!

Instead, you write simple tests that exercises only the functionality you want and the game is then to implement enough code to get the tests passing and then stop. If you need more features, write new tests and repeat. 

Not only do you avoid unnecessary, over-general code but writing the tests means when you do need to refactor to add new features you can easily check whether the old functionality is still working.</description>
		<content:encoded><![CDATA[<p>I also came to the same conclusion after working as a commercial programmer for a few years. When it comes to code &#8220;less is more&#8221;.</p>
<p>While it&#8217;s not a solution for everything, one thing test driven design does well is make you focus on the features that are essential. The best way to avoid useless features is not write them in the first place!</p>
<p>Instead, you write simple tests that exercises only the functionality you want and the game is then to implement enough code to get the tests passing and then stop. If you need more features, write new tests and repeat. </p>
<p>Not only do you avoid unnecessary, over-general code but writing the tests means when you do need to refactor to add new features you can easily check whether the old functionality is still working.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

