<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.3" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Two kinds of YAGNI</title>
	<link>http://www.m3p.co.uk/blog/2008/05/01/two-kinds-of-yagni/</link>
	<description>Working software daily</description>
	<pubDate>Thu, 24 Jul 2008 09:40:10 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.3</generator>

	<item>
		<title>By: Romilly Cocking</title>
		<link>http://www.m3p.co.uk/blog/2008/05/01/two-kinds-of-yagni/#comment-190</link>
		<dc:creator>Romilly Cocking</dc:creator>
		<pubDate>Mon, 05 May 2008 09:03:21 +0000</pubDate>
		<guid>http://www.m3p.co.uk/blog/2008/05/01/two-kinds-of-yagni/#comment-190</guid>
		<description>Couldn't agree more - though, like you, I don't do this as often as I know I should.

You express intent much more clearly with explicit types, and there are lots of other benefits. For example, you'll get much better auto-completion of method parameters in your IDE.</description>
		<content:encoded><![CDATA[<p>Couldn&#8217;t agree more - though, like you, I don&#8217;t do this as often as I know I should.</p>
<p>You express intent much more clearly with explicit types, and there are lots of other benefits. For example, you&#8217;ll get much better auto-completion of method parameters in your <span class="caps">IDE.</span></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: steve.freeman</title>
		<link>http://www.m3p.co.uk/blog/2008/05/01/two-kinds-of-yagni/#comment-189</link>
		<dc:creator>steve.freeman</dc:creator>
		<pubDate>Fri, 02 May 2008 05:28:26 +0000</pubDate>
		<guid>http://www.m3p.co.uk/blog/2008/05/01/two-kinds-of-yagni/#comment-189</guid>
		<description>@David. Thanks for your comment.

@Andrew

I suppose I'm (over)reacting to some styles of TDD that I've seen -- and that I've done myself. I think there's a worst-case combination with some interpretations of DTSTTCPW that leads to code that's all implementation.</description>
		<content:encoded><![CDATA[<p>@David. Thanks for your comment.</p>
<p>@Andrew</p>
<p>I suppose I&#8217;m (over)reacting to some styles of <span class="caps">TDD </span>that I&#8217;ve seen &#8212; and that I&#8217;ve done myself. I think there&#8217;s a worst-case combination with some interpretations of <span class="caps">DTSTTCPW </span>that leads to code that&#8217;s all implementation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andrew Walker</title>
		<link>http://www.m3p.co.uk/blog/2008/05/01/two-kinds-of-yagni/#comment-188</link>
		<dc:creator>Andrew Walker</dc:creator>
		<pubDate>Thu, 01 May 2008 17:30:12 +0000</pubDate>
		<guid>http://www.m3p.co.uk/blog/2008/05/01/two-kinds-of-yagni/#comment-188</guid>
		<description>Steve, I agree with your conclusions and I don't as much see this particular example as a case of YAGNI. Agile processes don't free us up from our responsibilities to apply sensible design practices to the problem. 

To me, this is a case of applying some domain knowledge and coming up with the conclusion 'I need an address now' - so you are going to need it. YAGNI would be applied however if you guessed what methods you needed for you address ahead of time - for example if you don't need a post code now, don't add it just in case. I also tend to use objects instead of built in types no matter how small - firstly to aid understanding and secondly to encapsulate any business knowledge where it belongs.</description>
		<content:encoded><![CDATA[<p>Steve, I agree with your conclusions and I don&#8217;t as much see this particular example as a case of <span class="caps">YAGNI.</span> Agile processes don&#8217;t free us up from our responsibilities to apply sensible design practices to the problem. </p>
<p>To me, this is a case of applying some domain knowledge and coming up with the conclusion &#8216;I need an address now&#8217; - so you are going to need it. <span class="caps">YAGNI </span>would be applied however if you guessed what methods you needed for you address ahead of time - for example if you don&#8217;t need a post code now, don&#8217;t add it just in case. I also tend to use objects instead of built in types no matter how small - firstly to aid understanding and secondly to encapsulate any business knowledge where it belongs.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Harvey</title>
		<link>http://www.m3p.co.uk/blog/2008/05/01/two-kinds-of-yagni/#comment-187</link>
		<dc:creator>David Harvey</dc:creator>
		<pubDate>Thu, 01 May 2008 11:56:42 +0000</pubDate>
		<guid>http://www.m3p.co.uk/blog/2008/05/01/two-kinds-of-yagni/#comment-187</guid>
		<description>&#62;&#62; it's not expressive in the domain of the code.

I like this a lot - a really succinct way of describing why so much code is such hard work to understand.

And a strong second for Abelson and Sussman. Teaching programming via functional abstraction now seems prescient...</description>
		<content:encoded><![CDATA[<p>&gt;&gt; it&#8217;s not expressive in the domain of the code.</p>
<p>I like this a lot - a really succinct way of describing why so much code is such hard work to understand.</p>
<p>And a strong second for Abelson and Sussman. Teaching programming via functional abstraction now seems prescient&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
