<?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: Performance is not a Check Box</title>
	<atom:link href="http://www.performanceengineer.com/blog/performance-is-not-a-check-box/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.performanceengineer.com/blog/performance-is-not-a-check-box/</link>
	<description>Software Performance Engineering &#38; Testing</description>
	<lastBuildDate>Tue, 18 May 2010 15:05:43 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: William Louth</title>
		<link>http://www.performanceengineer.com/blog/performance-is-not-a-check-box/comment-page-1/#comment-367</link>
		<dc:creator>William Louth</dc:creator>
		<pubDate>Fri, 18 Sep 2009 07:13:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.performanceengineer.com/blog/?p=181#comment-367</guid>
		<description>The key to successful performance engineering is in the creation or capture of both the software (steps, flows, interactions) and system (resources, concurrency, queues, contention plans) execution models.

Knowledge acquisition should drive any related efforts and it should start as early as possible and be archived so that others can understand the context for various technical decisions that impact scalability, reliability and performance.

William</description>
		<content:encoded><![CDATA[<p>The key to successful performance engineering is in the creation or capture of both the software (steps, flows, interactions) and system (resources, concurrency, queues, contention plans) execution models.</p>
<p>Knowledge acquisition should drive any related efforts and it should start as early as possible and be archived so that others can understand the context for various technical decisions that impact scalability, reliability and performance.</p>
<p>William</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andrew</title>
		<link>http://www.performanceengineer.com/blog/performance-is-not-a-check-box/comment-page-1/#comment-366</link>
		<dc:creator>Andrew</dc:creator>
		<pubDate>Tue, 15 Sep 2009 20:35:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.performanceengineer.com/blog/?p=181#comment-366</guid>
		<description>Charlie

One thing I find helps the performance engineering process is if during the design stage a simple performance model can be built that can identify what are the key performance critical areas. This then means the developers of those particular areas can then concentrate on producing good performing code. Less performance critical code areas can be given to junior programmers etc.</description>
		<content:encoded><![CDATA[<p>Charlie</p>
<p>One thing I find helps the performance engineering process is if during the design stage a simple performance model can be built that can identify what are the key performance critical areas. This then means the developers of those particular areas can then concentrate on producing good performing code. Less performance critical code areas can be given to junior programmers etc.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tola</title>
		<link>http://www.performanceengineer.com/blog/performance-is-not-a-check-box/comment-page-1/#comment-365</link>
		<dc:creator>Tola</dc:creator>
		<pubDate>Tue, 15 Sep 2009 16:44:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.performanceengineer.com/blog/?p=181#comment-365</guid>
		<description>Nice article...captures the meat of performance testing...however, one key component of performance  testing that is less mentioned is the role of functional testing, there are several options to handling this type of testing within an organization, some in parallel with performance testing based on completed scope testing, while others consider a fully functionally tested apps before engaging in performance testing. I&#039;ve had the opportunity to be involved in both, and there are no single bullet solution. The decision often boils down to cost, time-lines, and other external factors that influence the project.

Just to add my two cent!

Tola</description>
		<content:encoded><![CDATA[<p>Nice article&#8230;captures the meat of performance testing&#8230;however, one key component of performance  testing that is less mentioned is the role of functional testing, there are several options to handling this type of testing within an organization, some in parallel with performance testing based on completed scope testing, while others consider a fully functionally tested apps before engaging in performance testing. I&#8217;ve had the opportunity to be involved in both, and there are no single bullet solution. The decision often boils down to cost, time-lines, and other external factors that influence the project.</p>
<p>Just to add my two cent!</p>
<p>Tola</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chanson</title>
		<link>http://www.performanceengineer.com/blog/performance-is-not-a-check-box/comment-page-1/#comment-356</link>
		<dc:creator>Chanson</dc:creator>
		<pubDate>Tue, 18 Aug 2009 20:25:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.performanceengineer.com/blog/?p=181#comment-356</guid>
		<description>Charlie - Great article you wrote here =)</description>
		<content:encoded><![CDATA[<p>Charlie &#8211; Great article you wrote here =)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
