<?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: Quit Putting Your Solution In My Feature Request!</title>
	<atom:link href="http://www.codesqueeze.com/quit-putting-your-solution-in-my-feature-request/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.codesqueeze.com/quit-putting-your-solution-in-my-feature-request/</link>
	<description>Ideas for building efficient developers and software</description>
	<lastBuildDate>Mon, 30 Jan 2012 11:03:44 -0500</lastBuildDate>
	
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
	<item>
		<title>By: Chipping the web: November 24th -- Chip&#8217;s Quips</title>
		<link>http://www.codesqueeze.com/quit-putting-your-solution-in-my-feature-request/#comment-3042</link>
		<dc:creator>Chipping the web: November 24th -- Chip&#8217;s Quips</dc:creator>
		<pubDate>Tue, 25 Nov 2008 01:00:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.codesqueeze.com/quit-putting-your-solution-in-my-feature-request/#comment-3042</guid>
		<description>[...] Quit Putting Your Solution In My Feature Request!&quot;When a feature request already has a solution, developers never have the chance to learn the problem domain that they are developing for. It is necessary for quality solutions that the developer eventually becomes a domain expert in the problems that the software is trying to solve.&quot; Thanks, Arjan.Tags: requirements feature development design      Tags: combinator, combinators, del.icio.us, design, development, feature, homoiconic, iteration, javascript, memoizing, programming, recursion, requirements, ruby, weblog [...]</description>
		<content:encoded><![CDATA[<p>[...] Quit Putting Your Solution In My Feature Request!&quot;When a feature request already has a solution, developers never have the chance to learn the problem domain that they are developing for. It is necessary for quality solutions that the developer eventually becomes a domain expert in the problems that the software is trying to solve.&quot; Thanks, Arjan.Tags: requirements feature development design      Tags: combinator, combinators, del.icio.us, design, development, feature, homoiconic, iteration, javascript, memoizing, programming, recursion, requirements, ruby, weblog [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dew Drop - November 24, 2008 &#124; Alvin Ashcraft's Morning Dew</title>
		<link>http://www.codesqueeze.com/quit-putting-your-solution-in-my-feature-request/#comment-3041</link>
		<dc:creator>Dew Drop - November 24, 2008 &#124; Alvin Ashcraft's Morning Dew</dc:creator>
		<pubDate>Mon, 24 Nov 2008 13:10:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.codesqueeze.com/quit-putting-your-solution-in-my-feature-request/#comment-3041</guid>
		<description>[...] Quit Putting Your Solution in My Feature Request! (Max Pool) – Link of the Day [...]</description>
		<content:encoded><![CDATA[<p>[...] Quit Putting Your Solution in My Feature Request! (Max Pool) – Link of the Day [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tobin Harris</title>
		<link>http://www.codesqueeze.com/quit-putting-your-solution-in-my-feature-request/#comment-3040</link>
		<dc:creator>Tobin Harris</dc:creator>
		<pubDate>Mon, 24 Nov 2008 08:51:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.codesqueeze.com/quit-putting-your-solution-in-my-feature-request/#comment-3040</guid>
		<description>Yeah, I get these a lot, and it&#039;s frustrating! 

I find that use-case authoring guidelines given in most use-case books are pretty spot on: Write use cases at goal-level rather than task-level, this lets you focus on why users what a feature. And, don&#039;t discuss UI issues, they take the focus away from problem back and start focusing on solution.</description>
		<content:encoded><![CDATA[<p>Yeah, I get these a lot, and it&#8217;s frustrating! </p>
<p>I find that use-case authoring guidelines given in most use-case books are pretty spot on: Write use cases at goal-level rather than task-level, this lets you focus on why users what a feature. And, don&#8217;t discuss UI issues, they take the focus away from problem back and start focusing on solution.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

