<?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: Waterfall vs Agile: Development and Business</title>
	<atom:link href="http://www.makinggoodsoftware.com/2010/06/15/waterfall-vs-agile-development-and-business/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.makinggoodsoftware.com/2010/06/15/waterfall-vs-agile-development-and-business/</link>
	<description></description>
	<lastBuildDate>Fri, 03 Feb 2012 13:13:38 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Nate</title>
		<link>http://www.makinggoodsoftware.com/2010/06/15/waterfall-vs-agile-development-and-business/comment-page-1/#comment-8777</link>
		<dc:creator>Nate</dc:creator>
		<pubDate>Tue, 15 Jun 2010 21:37:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.makinggoodsoftware.com/?p=1366#comment-8777</guid>
		<description>I think that&#039;s a good summary.  However I have to disagree with at least one point.  Let me preface by saying that I&#039;m not advocating waterfall nor agile.  I personally think they both have their places.

&quot;It[agile] is also very strong on engineering practices (TDD, pair-programming, refactoring, etc)&quot;  

Now maybe this disagreement has more to do with what is software engineering, but from a broader engineering perspective, you see very little of this. 

I&#039;ve got a degree in electrical engineering, have worked my entire professional career and a few internships with engineers (electrical and mechanical mostly.)  Most engineers would be classified as a waterfall method, as opposed to agile.

In fact, this is often mentioned in the agile works.  Civil engineers (for example) start knowing a big chunk of the requirements to the buildings they are making.  Because if they think they&#039;re making a 5 story building, that causes a different foundation than a 50 story building.  

Obviously with software, it&#039;s easier to adapt to changes.  But I think waterfall is truly more of an engineering process than agile.  Unless, of course, we are to say that software engineering is so fundamentally different than every other engineering discipline that it needs to take an almost polar-opposite approach.</description>
		<content:encoded><![CDATA[<p>I think that&#8217;s a good summary.  However I have to disagree with at least one point.  Let me preface by saying that I&#8217;m not advocating waterfall nor agile.  I personally think they both have their places.</p>
<p>&#8220;It[agile] is also very strong on engineering practices (TDD, pair-programming, refactoring, etc)&#8221;  </p>
<p>Now maybe this disagreement has more to do with what is software engineering, but from a broader engineering perspective, you see very little of this. </p>
<p>I&#8217;ve got a degree in electrical engineering, have worked my entire professional career and a few internships with engineers (electrical and mechanical mostly.)  Most engineers would be classified as a waterfall method, as opposed to agile.</p>
<p>In fact, this is often mentioned in the agile works.  Civil engineers (for example) start knowing a big chunk of the requirements to the buildings they are making.  Because if they think they&#8217;re making a 5 story building, that causes a different foundation than a 50 story building.  </p>
<p>Obviously with software, it&#8217;s easier to adapt to changes.  But I think waterfall is truly more of an engineering process than agile.  Unless, of course, we are to say that software engineering is so fundamentally different than every other engineering discipline that it needs to take an almost polar-opposite approach.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

