<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.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 for Skyway Software Blog</title>
	<link>http://www.skywaysoftware.com/blog</link>
	<description>Simplifying Software Delivery™</description>
	<pubDate>Wed, 10 Mar 2010 05:22:40 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.3</generator>
		<item>
		<title>Comment on Simulation doesn&#8217;t have to mean throw away Software by Mike Evans</title>
		<link>http://www.skywaysoftware.com/blog/?p=34#comment-568</link>
		<dc:creator>Mike Evans</dc:creator>
		<pubDate>Mon, 05 May 2008 20:20:08 +0000</pubDate>
		<guid>http://www.skywaysoftware.com/blog/?p=34#comment-568</guid>
		<description>Hi Tom,

You manage a very nice community site - lot's of good content.  

I agree that using the previous era of development tools to leverage the code created to support prototyping efforts was problematic at best - and I have battle scars to prove it.  Yet, I always felt like we missed a business opportunity by not using the code created during prototyping - throwing away work just seemed fundamentally wrong.  

The innovation that makes me revisit leveraging the work done during prototyping is the recent advancement in modeling concepts based on the &lt;a href="http://www.eclipse.org/modeling/emf/" rel="nofollow"&gt;eclipse modeling framework&lt;/a&gt; project coupled with smart pairing concepts that enable the business and technical folks to collaborate using a common toolset.  Adding visual modeling frameworks that guide and cover the user interface, controlling actions, business logic and data access gives new life to leveraging the output from prototyping efforts into the development phases of the project.</description>
		<content:encoded><![CDATA[<p>Hi Tom,</p>
<p>You manage a very nice community site - lot&#8217;s of good content.  </p>
<p>I agree that using the previous era of development tools to leverage the code created to support prototyping efforts was problematic at best - and I have battle scars to prove it.  Yet, I always felt like we missed a business opportunity by not using the code created during prototyping - throwing away work just seemed fundamentally wrong.  </p>
<p>The innovation that makes me revisit leveraging the work done during prototyping is the recent advancement in modeling concepts based on the <a href="http://www.eclipse.org/modeling/emf/" rel="nofollow">eclipse modeling framework</a> project coupled with smart pairing concepts that enable the business and technical folks to collaborate using a common toolset.  Adding visual modeling frameworks that guide and cover the user interface, controlling actions, business logic and data access gives new life to leveraging the output from prototyping efforts into the development phases of the project.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Simulation doesn&#8217;t have to mean throw away Software by Tom Humbarger</title>
		<link>http://www.skywaysoftware.com/blog/?p=34#comment-530</link>
		<dc:creator>Tom Humbarger</dc:creator>
		<pubDate>Fri, 02 May 2008 04:16:51 +0000</pubDate>
		<guid>http://www.skywaysoftware.com/blog/?p=34#comment-530</guid>
		<description>I ran across this blog excerpt from Coding Horror...

"Prototypes are designed to be thrown away. If you can't bring yourself to throw the prototype away, then stop prototyping."

http://www.codinghorror.com/blog/archives/000256.html

The blog post also goes on to discuss the 5 laws of prototyping:

1. The answer to any prototype / feasibility question is always yes 
2. Whatever poor coding practices you use to build your prototype will be replicated in the final production version 
3. No matter how poor the performance of the prototype the production version will be much worse 
4. Once in production a prototype will never die 
5. Any controls used to build the prototype will be used in the production version even if they aren't appropriate 


Tom Humbarger, Community Manager
Catalyze Community - http://www.mycatalyze.org</description>
		<content:encoded><![CDATA[<p>I ran across this blog excerpt from Coding Horror&#8230;</p>
<p>&#8220;Prototypes are designed to be thrown away. If you can&#8217;t bring yourself to throw the prototype away, then stop prototyping.&#8221;</p>
<p><a href="http://www.codinghorror.com/blog/archives/000256.html" rel="nofollow">http://www.codinghorror.com/blog/archives/000256.html</a></p>
<p>The blog post also goes on to discuss the 5 laws of prototyping:</p>
<p>1. The answer to any prototype / feasibility question is always yes<br />
2. Whatever poor coding practices you use to build your prototype will be replicated in the final production version<br />
3. No matter how poor the performance of the prototype the production version will be much worse<br />
4. Once in production a prototype will never die<br />
5. Any controls used to build the prototype will be used in the production version even if they aren&#8217;t appropriate </p>
<p>Tom Humbarger, Community Manager<br />
Catalyze Community - <a href="http://www.mycatalyze.org" rel="nofollow">http://www.mycatalyze.org</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Hope Is Not a Strategy by David Daniels</title>
		<link>http://www.skywaysoftware.com/blog/?p=29#comment-343</link>
		<dc:creator>David Daniels</dc:creator>
		<pubDate>Sat, 12 Apr 2008 14:04:13 +0000</pubDate>
		<guid>http://www.skywaysoftware.com/blog/?p=29#comment-343</guid>
		<description>Nicely put.  We all want Chart C, but as Seth put it to us in "The Dip", we often don't drive through to the other side to see the fruits of our efforts.</description>
		<content:encoded><![CDATA[<p>Nicely put.  We all want Chart C, but as Seth put it to us in &#8220;The Dip&#8221;, we often don&#8217;t drive through to the other side to see the fruits of our efforts.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on It&#8217;s All About the Developers by It’s All About the Developers</title>
		<link>http://www.skywaysoftware.com/blog/?p=24#comment-88</link>
		<dc:creator>It’s All About the Developers</dc:creator>
		<pubDate>Wed, 13 Feb 2008 04:25:30 +0000</pubDate>
		<guid>http://www.skywaysoftware.com/blog/?p=24#comment-88</guid>
		<description>[...] RyanK wrote an interesting post today onHere&#8217;s a quick excerptIt’s an important finding not only as an indicator of our overall quality of life, health of the union, and rank within the world, but also as a barometer for most of the software industry. Developers are the lifeblood of the ISVs. &#8230; [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] RyanK wrote an interesting post today onHere&#8217;s a quick excerptIt’s an important finding not only as an indicator of our overall quality of life, health of the union, and rank within the world, but also as a barometer for most of the software industry. Developers are the lifeblood of the ISVs. &#8230; [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on It&#8217;s All About the Developers by &#187; It’s All About the Developers</title>
		<link>http://www.skywaysoftware.com/blog/?p=24#comment-87</link>
		<dc:creator>&#187; It’s All About the Developers</dc:creator>
		<pubDate>Wed, 13 Feb 2008 04:02:47 +0000</pubDate>
		<guid>http://www.skywaysoftware.com/blog/?p=24#comment-87</guid>
		<description>[...] RyanK wrote an interesting post today onHere&#8217;s a quick excerptIt’s an important finding not only as an indicator of our overall quality of life, health of the union, and rank within the world, but also as a barometer for most of the software industry. Developers are the lifeblood of the ISVs. &#8230; [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] RyanK wrote an interesting post today onHere&#8217;s a quick excerptIt’s an important finding not only as an indicator of our overall quality of life, health of the union, and rank within the world, but also as a barometer for most of the software industry. Developers are the lifeblood of the ISVs. &#8230; [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on How Would You Handle This Rework Project???!!! by David Castro</title>
		<link>http://www.skywaysoftware.com/blog/?p=16#comment-24</link>
		<dc:creator>David Castro</dc:creator>
		<pubDate>Thu, 10 Jan 2008 14:13:48 +0000</pubDate>
		<guid>http://www.skywaysoftware.com/blog/?p=16#comment-24</guid>
		<description>A fair clarification, thank you.  And my post was an extenstion to yours with a discussion of risk implications and one conceptual alternative as a potential remedy.  As I see it, hundreds of 787 orders may be affected and if I were the Marketing guy at Airbus, Id be running a FUD campaign and offerring "Switch from Boeing" incentives as aggressively as possible.</description>
		<content:encoded><![CDATA[<p>A fair clarification, thank you.  And my post was an extenstion to yours with a discussion of risk implications and one conceptual alternative as a potential remedy.  As I see it, hundreds of 787 orders may be affected and if I were the Marketing guy at Airbus, Id be running a FUD campaign and offerring &#8220;Switch from Boeing&#8221; incentives as aggressively as possible.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on How Would You Handle This Rework Project???!!! by Michael Krigsman</title>
		<link>http://www.skywaysoftware.com/blog/?p=16#comment-21</link>
		<dc:creator>Michael Krigsman</dc:creator>
		<pubDate>Thu, 10 Jan 2008 00:28:36 +0000</pubDate>
		<guid>http://www.skywaysoftware.com/blog/?p=16#comment-21</guid>
		<description>To clarify one point: while the in-flight systems and entertainment networks do connect, there is nothing to suggest that passengers have access to the flight network.  This is more about the potential risk that can result from the physical connection of the two networks.</description>
		<content:encoded><![CDATA[<p>To clarify one point: while the in-flight systems and entertainment networks do connect, there is nothing to suggest that passengers have access to the flight network.  This is more about the potential risk that can result from the physical connection of the two networks.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
