<?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: 3 Simple Ways To Avoid Making Code Smells</title>
	<atom:link href="http://www.codesqueeze.com/3-simple-ways-to-avoid-making-code-smells/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.codesqueeze.com/3-simple-ways-to-avoid-making-code-smells/</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: Jeremy N</title>
		<link>http://www.codesqueeze.com/3-simple-ways-to-avoid-making-code-smells/#comment-379</link>
		<dc:creator>Jeremy N</dc:creator>
		<pubDate>Sat, 20 Oct 2007 13:40:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.codesqueeze.com/3-simple-ways-to-avoid-making-code-smells/#comment-379</guid>
		<description>@Point 2
I feel one of the continuous/BIGGEST failures of developers/project managers/business analysts is the 
“unwillingness” to tell clients/managers what it will take to make a change in a project. We need to spend time before the project training our clients/managers that changes will have consequences. Then when they come with changes, which they will come with changes, don’t worry about deciding for them, just give them the fully loaded amount of work that it will take to CORRECTLY do the change (including refactoring). 

If you trained them correctly they should realize that the closer to the completion of the project the more impact that change will have.</description>
		<content:encoded><![CDATA[<p>@Point 2<br />
I feel one of the continuous/BIGGEST failures of developers/project managers/business analysts is the<br />
“unwillingness” to tell clients/managers what it will take to make a change in a project. We need to spend time before the project training our clients/managers that changes will have consequences. Then when they come with changes, which they will come with changes, don’t worry about deciding for them, just give them the fully loaded amount of work that it will take to CORRECTLY do the change (including refactoring). </p>
<p>If you trained them correctly they should realize that the closer to the completion of the project the more impact that change will have.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

