<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments for Liz Keogh, lunivore</title>
	<atom:link href="http://lizkeogh.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://lizkeogh.com</link>
	<description>you&#039;re different</description>
	<lastBuildDate>Wed, 15 May 2013 10:09:24 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>Comment on They&#8217;re not User Stories by Liz</title>
		<link>http://lizkeogh.com/2010/02/02/theyre-not-user-stories/#comment-4301</link>
		<dc:creator><![CDATA[Liz]]></dc:creator>
		<pubDate>Wed, 15 May 2013 10:09:24 +0000</pubDate>
		<guid isPermaLink="false">http://lizkeogh.com/?p=553#comment-4301</guid>
		<description><![CDATA[Marian, there are no pictures on this post. It&#039;s possible some of the pictures have gone missing because I&#039;ve moved the blog recently; please let me know which post you&#039;re looking at and I&#039;ll work to put them back. Just leave a comment on the respective post telling me to fix the pictures! :)]]></description>
		<content:encoded><![CDATA[<p>Marian, there are no pictures on this post. It&#8217;s possible some of the pictures have gone missing because I&#8217;ve moved the blog recently; please let me know which post you&#8217;re looking at and I&#8217;ll work to put them back. Just leave a comment on the respective post telling me to fix the pictures! <img src='http://s0.wp.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on They&#8217;re not User Stories by Alternative energy</title>
		<link>http://lizkeogh.com/2010/02/02/theyre-not-user-stories/#comment-4300</link>
		<dc:creator><![CDATA[Alternative energy]]></dc:creator>
		<pubDate>Wed, 15 May 2013 08:45:12 +0000</pubDate>
		<guid isPermaLink="false">http://lizkeogh.com/?p=553#comment-4300</guid>
		<description><![CDATA[Hmm is anyone else having problems with the pictures on 
this blog loading? I&#039;m trying to determine if its a problem on my end or if it&#039;s the blog.
Any responses would be greatly appreciated.]]></description>
		<content:encoded><![CDATA[<p>Hmm is anyone else having problems with the pictures on<br />
this blog loading? I&#8217;m trying to determine if its a problem on my end or if it&#8217;s the blog.<br />
Any responses would be greatly appreciated.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Step Away from the Tools by Joseph Wilk on Acceptance Testing in a Startup &#124; Coding Is Like Cooking</title>
		<link>http://lizkeogh.com/2011/03/04/step-away-from-the-tools/#comment-4296</link>
		<dc:creator><![CDATA[Joseph Wilk on Acceptance Testing in a Startup &#124; Coding Is Like Cooking]]></dc:creator>
		<pubDate>Wed, 08 May 2013 09:20:37 +0000</pubDate>
		<guid isPermaLink="false">http://lizkeogh.com/?p=649#comment-4296</guid>
		<description><![CDATA[[...] fewer scenarios with Cucumber may be one of the reasons Liz Keogh wrote her blog post &#8220;Step away from the tools&#8220;. Or maybe the blog came first, I don&#8217;t know. The advice is the same, in any case [...]]]></description>
		<content:encoded><![CDATA[<p>[...] fewer scenarios with Cucumber may be one of the reasons Liz Keogh wrote her blog post &#8220;Step away from the tools&#8220;. Or maybe the blog came first, I don&#8217;t know. The advice is the same, in any case [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on About by Five Blogs – 3 May 2013 &#124; 5blogs</title>
		<link>http://lizkeogh.com/about/#comment-4294</link>
		<dc:creator><![CDATA[Five Blogs – 3 May 2013 &#124; 5blogs]]></dc:creator>
		<pubDate>Fri, 03 May 2013 04:34:31 +0000</pubDate>
		<guid isPermaLink="false">http://lunivore.wordpress.com/?page_id=2#comment-4294</guid>
		<description><![CDATA[[...] Respect for People: it’s a Test, not a Pillar Written by: Liz Keogh  [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Respect for People: it’s a Test, not a Pillar Written by: Liz Keogh  [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Respect for People: it&#8217;s a Test, not a Pillar by Five Blogs – 3 May 2013 &#124; 5blogs</title>
		<link>http://lizkeogh.com/2013/05/01/respect-for-people-its-a-test-not-a-pillar/#comment-4293</link>
		<dc:creator><![CDATA[Five Blogs – 3 May 2013 &#124; 5blogs]]></dc:creator>
		<pubDate>Fri, 03 May 2013 04:34:28 +0000</pubDate>
		<guid isPermaLink="false">http://lizkeogh.com/?p=1264#comment-4293</guid>
		<description><![CDATA[[...] Respect for People: it’s a Test, not a Pillar Written by: Liz Keogh [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Respect for People: it’s a Test, not a Pillar Written by: Liz Keogh [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Step Away from the Tools by Examples!</title>
		<link>http://lizkeogh.com/2011/03/04/step-away-from-the-tools/#comment-4289</link>
		<dc:creator><![CDATA[Examples!]]></dc:creator>
		<pubDate>Mon, 29 Apr 2013 08:35:36 +0000</pubDate>
		<guid isPermaLink="false">http://lizkeogh.com/?p=649#comment-4289</guid>
		<description><![CDATA[[...] be able to disable from the Properties menu. That said I’d recommend when writing features to step away from tools like Visual Studio and focus on collaborating with business stakeholders in an environment that [...]]]></description>
		<content:encoded><![CDATA[<p>[...] be able to disable from the Properties menu. That said I’d recommend when writing features to step away from tools like Visual Studio and focus on collaborating with business stakeholders in an environment that [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Step Away from the Tools by Examples!</title>
		<link>http://lizkeogh.com/2011/03/04/step-away-from-the-tools/#comment-4288</link>
		<dc:creator><![CDATA[Examples!]]></dc:creator>
		<pubDate>Sun, 28 Apr 2013 22:53:46 +0000</pubDate>
		<guid isPermaLink="false">http://lizkeogh.com/?p=649#comment-4288</guid>
		<description><![CDATA[[...] be able to turn off from the Properties menu. That said I’d recommend when writing features to step away from tools like Visual Studio anyway and focus on collaborating with business stakeholders in an environment [...]]]></description>
		<content:encoded><![CDATA[<p>[...] be able to turn off from the Properties menu. That said I’d recommend when writing features to step away from tools like Visual Studio anyway and focus on collaborating with business stakeholders in an environment [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on If you can&#8217;t write tests first, at least write tests second by ☕ J. B. Rainsberger (@jbrains)</title>
		<link>http://lizkeogh.com/2013/04/24/if-you-cant-write-tests-first-at-least-write-tests-second/#comment-4284</link>
		<dc:creator><![CDATA[☕ J. B. Rainsberger (@jbrains)]]></dc:creator>
		<pubDate>Fri, 26 Apr 2013 14:20:18 +0000</pubDate>
		<guid isPermaLink="false">http://lizkeogh.com/?p=1249#comment-4284</guid>
		<description><![CDATA[The more I work with legacy code, the more I recommend the &quot;incremental rewrite&quot; style over refactoring code in place. This means picking a small part of the system, understanding what it does (or ought to do), test-driving a replacement for it, then rerouting requests from old to new. Of course, I recommend doing this in small batches in order to make steady progress and avoid falling into the trap of rebuilding more than we need. Thus, the emphasis on &quot;incremental&quot; over &quot;rewrite&quot;.

Because of this, I find the spike-and-stabilise pattern troubling in the large and manageable in the small. By this, I mean that so long as one keeps the spikes quite small, one can get away with stabilising it with tests after the fact. I can&#039;t easily define &quot;small enough&quot; here, as I imagine it depends on a host of factors that I can&#039;t enumerate well enough to try. Perhaps one learns &quot;small enough&quot; from experience. (Does that make the whole statement beg the question? It might.) Perhaps I do better to say the size of thing one can safely spike-and-stabilise varies from programmer to programmer, and most programmers most of the time overestimate what they can safely spike-and-stabilise, so I urge them to err on the side of spike-and-rewrite.

How to &quot;increase&quot; the size of thing one can safely spike-and-stabilise? Build more stuff well, observe your blindspots, notice your design tendencies, write code in reversible steps, use version control aggressively, reach the point where you can see 10 tests ahead. You&#039;ll probably still write the tests in your head, or at least sketch out the sets of tests in your head, but not write them. You&#039;ll use other techniques to lower the cost of mistakes. It&#039;ll be fine. I feel comfortable doing this now; I refactor without tests quite a lot; it took me at least five years to become even the slightest bit comfortable with it. Everyone differs in how long it will take. Everyone probably underestimates how long it will take. Everyone probably overestimates how ready they are. :)]]></description>
		<content:encoded><![CDATA[<p>The more I work with legacy code, the more I recommend the &#8220;incremental rewrite&#8221; style over refactoring code in place. This means picking a small part of the system, understanding what it does (or ought to do), test-driving a replacement for it, then rerouting requests from old to new. Of course, I recommend doing this in small batches in order to make steady progress and avoid falling into the trap of rebuilding more than we need. Thus, the emphasis on &#8220;incremental&#8221; over &#8220;rewrite&#8221;.</p>
<p>Because of this, I find the spike-and-stabilise pattern troubling in the large and manageable in the small. By this, I mean that so long as one keeps the spikes quite small, one can get away with stabilising it with tests after the fact. I can&#8217;t easily define &#8220;small enough&#8221; here, as I imagine it depends on a host of factors that I can&#8217;t enumerate well enough to try. Perhaps one learns &#8220;small enough&#8221; from experience. (Does that make the whole statement beg the question? It might.) Perhaps I do better to say the size of thing one can safely spike-and-stabilise varies from programmer to programmer, and most programmers most of the time overestimate what they can safely spike-and-stabilise, so I urge them to err on the side of spike-and-rewrite.</p>
<p>How to &#8220;increase&#8221; the size of thing one can safely spike-and-stabilise? Build more stuff well, observe your blindspots, notice your design tendencies, write code in reversible steps, use version control aggressively, reach the point where you can see 10 tests ahead. You&#8217;ll probably still write the tests in your head, or at least sketch out the sets of tests in your head, but not write them. You&#8217;ll use other techniques to lower the cost of mistakes. It&#8217;ll be fine. I feel comfortable doing this now; I refactor without tests quite a lot; it took me at least five years to become even the slightest bit comfortable with it. Everyone differs in how long it will take. Everyone probably underestimates how long it will take. Everyone probably overestimates how ready they are. <img src='http://s0.wp.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on If you can&#8217;t write tests first, at least write tests second by Geek Reading April 25, 2013 &#124; Regular Geek</title>
		<link>http://lizkeogh.com/2013/04/24/if-you-cant-write-tests-first-at-least-write-tests-second/#comment-4283</link>
		<dc:creator><![CDATA[Geek Reading April 25, 2013 &#124; Regular Geek]]></dc:creator>
		<pubDate>Thu, 25 Apr 2013 17:00:54 +0000</pubDate>
		<guid isPermaLink="false">http://lizkeogh.com/?p=1249#comment-4283</guid>
		<description><![CDATA[[...] If you can’t write tests first, at least write tests second (Liz Keogh, lunivore) [...]]]></description>
		<content:encoded><![CDATA[<p>[...] If you can’t write tests first, at least write tests second (Liz Keogh, lunivore) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on If you can&#8217;t write tests first, at least write tests second by Liz</title>
		<link>http://lizkeogh.com/2013/04/24/if-you-cant-write-tests-first-at-least-write-tests-second/#comment-4280</link>
		<dc:creator><![CDATA[Liz]]></dc:creator>
		<pubDate>Thu, 25 Apr 2013 14:06:01 +0000</pubDate>
		<guid isPermaLink="false">http://lizkeogh.com/?p=1249#comment-4280</guid>
		<description><![CDATA[There&#039;s a difference between refactoring as part of TDD and refactoring in order to bring a legacy code base under test in the first place. The second comes with a whole host of other problems, like being able to understand the behaviour of the code when it&#039;s completely lacking in the usual documentation (ie: unit tests).

But you&#039;re right, I&#039;m conflating the issue, as well as mixing it up with the fact that when I do BDD at a unit level I tend to write pretty nice code (because I&#039;m thinking about the responsibilities of the classes, etc.).

I think of the TDD cycle as producing good, clean code at the end, regardless of whether it happens that way because of nice BDDism or because we clean it up one small bit at a time. I would love people to have the ability to produce good, clean code when there&#039;s more than just a small bit to clean up, and I believe that skill is different, and hugely important. Thank you for prompting me to clarify my thoughts here.]]></description>
		<content:encoded><![CDATA[<p>There&#8217;s a difference between refactoring as part of TDD and refactoring in order to bring a legacy code base under test in the first place. The second comes with a whole host of other problems, like being able to understand the behaviour of the code when it&#8217;s completely lacking in the usual documentation (ie: unit tests).</p>
<p>But you&#8217;re right, I&#8217;m conflating the issue, as well as mixing it up with the fact that when I do BDD at a unit level I tend to write pretty nice code (because I&#8217;m thinking about the responsibilities of the classes, etc.).</p>
<p>I think of the TDD cycle as producing good, clean code at the end, regardless of whether it happens that way because of nice BDDism or because we clean it up one small bit at a time. I would love people to have the ability to produce good, clean code when there&#8217;s more than just a small bit to clean up, and I believe that skill is different, and hugely important. Thank you for prompting me to clarify my thoughts here.</p>
]]></content:encoded>
	</item>
</channel>
</rss>