<?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"
	>
<channel>
	<title>Comments on: You Can Pay Me Now, Or&#8230;</title>
	<atom:link href="http://www.brianberliner.com/2006/09/14/you-can-pay-me-now-or/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.brianberliner.com/2006/09/14/you-can-pay-me-now-or/</link>
	<description>This is your brain on: Venture Capital and Technology</description>
	<pubDate>Thu, 20 Nov 2008 23:05:23 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6-bleeding2</generator>
		<item>
		<title>By: Cate</title>
		<link>http://www.brianberliner.com/2006/09/14/you-can-pay-me-now-or/#comment-6483</link>
		<dc:creator>Cate</dc:creator>
		<pubDate>Fri, 15 Sep 2006 18:14:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.brianberliner.com/2006/09/14/you-can-pay-me-now-or/#comment-6483</guid>
		<description>Wonderful Brian:

SaaS is the preferred approach...fortunately the current market leader in my space has utilized this structure for a number of firms that they provide the service to...so I wouldn't have to sell a new method.

I really like and appreciate your comments on QA. Especially the idea that the QA leader is a peer to others on the development team. And that method and process can evolve given the strengths of those involved. Not being a developer myself I'm not wedded to any methodology but I do believe that a system should be in place.

Many thanks, Cate</description>
		<content:encoded><![CDATA[<p>Wonderful Brian:</p>
<p>SaaS is the preferred approach&#8230;fortunately the current market leader in my space has utilized this structure for a number of firms that they provide the service to&#8230;so I wouldn&#8217;t have to sell a new method.</p>
<p>I really like and appreciate your comments on QA. Especially the idea that the QA leader is a peer to others on the development team. And that method and process can evolve given the strengths of those involved. Not being a developer myself I&#8217;m not wedded to any methodology but I do believe that a system should be in place.</p>
<p>Many thanks, Cate</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian Berliner</title>
		<link>http://www.brianberliner.com/2006/09/14/you-can-pay-me-now-or/#comment-6482</link>
		<dc:creator>Brian Berliner</dc:creator>
		<pubDate>Fri, 15 Sep 2006 15:55:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.brianberliner.com/2006/09/14/you-can-pay-me-now-or/#comment-6482</guid>
		<description>Hi Cate,

Thanks for the comments.

The Web and "Software as a Service" has fundamentally changed the way that we build and deploy software. We're seeing less "packaged" software in a box or on a CD and more websites that, in fact, are the product (as a service). This fundamental change has allowed for releases to be done in a much lighter-weight way. If you have your processes in place (and an automated test suite), you can even release product features and bug fixes multiple times per day. Flickr certainly did this.

The benefit of SaaS companies is that everyone gets the upgrade and bugfix all at once. And, the software is always in a very controlled environment, being upgraded by the folks that wrote the code. These are big advantages to everyone. I'm a big SaaS fan. This model also supports strong business models.

Test-First is finding pockets of supporters, certianly. And, those pockets are growing. Each development organization tends to morph their own processes to the strengths and weaknesses of the developers. Only the best organizations can really pull of a Test-First approach, in my experience.

In building out your QA organization, make sure that you have hired the leader, put him/her as a peer to the other software developers in your org, and work with him/her on building out the QA group's approach and metrics and reward structure. It's OK to have lots of "junior engineers" in QA - you just need to keep them focused on writing code, not doing manual tests. Sell the job to them as the best place to write the most code possible. And, it's true. A well-run QA group will, hands down, write more code than is in the actual shipping product.

Make QA a career within your organization.</description>
		<content:encoded><![CDATA[<p>Hi Cate,</p>
<p>Thanks for the comments.</p>
<p>The Web and &#8220;Software as a Service&#8221; has fundamentally changed the way that we build and deploy software. We&#8217;re seeing less &#8220;packaged&#8221; software in a box or on a CD and more websites that, in fact, are the product (as a service). This fundamental change has allowed for releases to be done in a much lighter-weight way. If you have your processes in place (and an automated test suite), you can even release product features and bug fixes multiple times per day. Flickr certainly did this.</p>
<p>The benefit of SaaS companies is that everyone gets the upgrade and bugfix all at once. And, the software is always in a very controlled environment, being upgraded by the folks that wrote the code. These are big advantages to everyone. I&#8217;m a big SaaS fan. This model also supports strong business models.</p>
<p>Test-First is finding pockets of supporters, certianly. And, those pockets are growing. Each development organization tends to morph their own processes to the strengths and weaknesses of the developers. Only the best organizations can really pull of a Test-First approach, in my experience.</p>
<p>In building out your QA organization, make sure that you have hired the leader, put him/her as a peer to the other software developers in your org, and work with him/her on building out the QA group&#8217;s approach and metrics and reward structure. It&#8217;s OK to have lots of &#8220;junior engineers&#8221; in QA - you just need to keep them focused on writing code, not doing manual tests. Sell the job to them as the best place to write the most code possible. And, it&#8217;s true. A well-run QA group will, hands down, write more code than is in the actual shipping product.</p>
<p>Make QA a career within your organization.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cate</title>
		<link>http://www.brianberliner.com/2006/09/14/you-can-pay-me-now-or/#comment-6481</link>
		<dc:creator>Cate</dc:creator>
		<pubDate>Fri, 15 Sep 2006 15:16:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.brianberliner.com/2006/09/14/you-can-pay-me-now-or/#comment-6481</guid>
		<description>Excellent post...I'm not that knowledgeable yet about software development yet it would seem to be a lot more satisfying to those involved to have a series of small wins that builds to a clean, functional whole.

Is the "Test First" approach widely used?

It seems more common to have the QA/testing function as the end point of the development cycle.

My business plan shows salary lines for "junior engineers" in QA...hum...may rethink that...</description>
		<content:encoded><![CDATA[<p>Excellent post&#8230;I&#8217;m not that knowledgeable yet about software development yet it would seem to be a lot more satisfying to those involved to have a series of small wins that builds to a clean, functional whole.</p>
<p>Is the &#8220;Test First&#8221; approach widely used?</p>
<p>It seems more common to have the QA/testing function as the end point of the development cycle.</p>
<p>My business plan shows salary lines for &#8220;junior engineers&#8221; in QA&#8230;hum&#8230;may rethink that&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.367 seconds -->
