<?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: Immovable Object versus Unstoppable Force: Capex and the Marginal Cost of Production</title>
	<atom:link href="http://www.threeriversinstitute.org/blog/?feed=rss2&#038;p=268" rel="self" type="application/rss+xml" />
	<link>http://www.threeriversinstitute.org/blog/?p=268</link>
	<description>Thoughts on programming</description>
	<lastBuildDate>Thu, 29 Jul 2010 21:19:43 -0400</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Kragen Javier Sitaker</title>
		<link>http://www.threeriversinstitute.org/blog/?p=268&#038;cpage=1#comment-920</link>
		<dc:creator>Kragen Javier Sitaker</dc:creator>
		<pubDate>Tue, 14 Jul 2009 23:02:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.threeriversinstitute.org/blog/?p=268#comment-920</guid>
		<description>The marginal cost of production isn&#039;t just OPEX; risk-adjusted depreciation on CAPEX is part of it too.</description>
		<content:encoded><![CDATA[<p>The marginal cost of production isn&#8217;t just OPEX; risk-adjusted depreciation on CAPEX is part of it too.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: KentBeck</title>
		<link>http://www.threeriversinstitute.org/blog/?p=268&#038;cpage=1#comment-822</link>
		<dc:creator>KentBeck</dc:creator>
		<pubDate>Thu, 02 Jul 2009 15:36:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.threeriversinstitute.org/blog/?p=268#comment-822</guid>
		<description>If the parties are close enough, the shared third machine is a good solution. I am often 400-500 ms away from my programming partners (that pesky speed of light :-). I haven&#039;t tried a shared third server in such a situation.</description>
		<content:encoded><![CDATA[<p>If the parties are close enough, the shared third machine is a good solution. I am often 400-500 ms away from my programming partners (that pesky speed of light <img src='http://www.threeriversinstitute.org/blog/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> . I haven&#8217;t tried a shared third server in such a situation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Willem van den Ende</title>
		<link>http://www.threeriversinstitute.org/blog/?p=268&#038;cpage=1#comment-820</link>
		<dc:creator>Willem van den Ende</dc:creator>
		<pubDate>Thu, 02 Jul 2009 15:03:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.threeriversinstitute.org/blog/?p=268#comment-820</guid>
		<description>Kent,

Screen sharing can be made symmetric. My solution to the &#039;local pair partner has the advantage&#039; is to install vnc on a remote server (with much better internet connection than either partner has) that both partners log in to, so neither has the advantage. 
I noticed Andy Palmer and Antony Marcano use dimdim.com, which should be able to support symmetric remote pairing (I wasn&#039;t successful with that yet).</description>
		<content:encoded><![CDATA[<p>Kent,</p>
<p>Screen sharing can be made symmetric. My solution to the &#8216;local pair partner has the advantage&#8217; is to install vnc on a remote server (with much better internet connection than either partner has) that both partners log in to, so neither has the advantage.<br />
I noticed Andy Palmer and Antony Marcano use dimdim.com, which should be able to support symmetric remote pairing (I wasn&#8217;t successful with that yet).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: KentBeck</title>
		<link>http://www.threeriversinstitute.org/blog/?p=268&#038;cpage=1#comment-818</link>
		<dc:creator>KentBeck</dc:creator>
		<pubDate>Thu, 02 Jul 2009 01:45:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.threeriversinstitute.org/blog/?p=268#comment-818</guid>
		<description>My experience with remote pairing (&gt;1000 hours at this point) is that the difficult conflict merge scenarios aren&#039;t that important. They have to be implemented for completeness. Mostly what I need is immediate feedback on the local screen when I&#039;m typing and the same for my partner. The asymmetry of screen sharing means that one person does most of the typing. Most of the time only one person will be typing at a time. I suppose the simplest conflict resolution strategy is to undo both party&#039;s typing if a conflict is detected. Then we can have a chuckle and a conversation about who will be in control. That&#039;s a good enough idea that I&#039;m tempted to implement it.</description>
		<content:encoded><![CDATA[<p>My experience with remote pairing (>1000 hours at this point) is that the difficult conflict merge scenarios aren&#8217;t that important. They have to be implemented for completeness. Mostly what I need is immediate feedback on the local screen when I&#8217;m typing and the same for my partner. The asymmetry of screen sharing means that one person does most of the typing. Most of the time only one person will be typing at a time. I suppose the simplest conflict resolution strategy is to undo both party&#8217;s typing if a conflict is detected. Then we can have a chuckle and a conversation about who will be in control. That&#8217;s a good enough idea that I&#8217;m tempted to implement it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: KentBeck</title>
		<link>http://www.threeriversinstitute.org/blog/?p=268&#038;cpage=1#comment-817</link>
		<dc:creator>KentBeck</dc:creator>
		<pubDate>Thu, 02 Jul 2009 01:35:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.threeriversinstitute.org/blog/?p=268#comment-817</guid>
		<description>Jeff,

You and I have both experienced that developer tools aren&#039;t a great business opportunity, haven&#039;t we? Ideally I would find a related topic (see Eric Ries&#039; &quot;pivot&quot; concept), like testing tools for testers, say, or reporting tools for project managers. However, I don&#039;t have one of those in mind. I&#039;m also willing to go further afield, but again, I don&#039;t see any prospects on the horizon.</description>
		<content:encoded><![CDATA[<p>Jeff,</p>
<p>You and I have both experienced that developer tools aren&#8217;t a great business opportunity, haven&#8217;t we? Ideally I would find a related topic (see Eric Ries&#8217; &#8220;pivot&#8221; concept), like testing tools for testers, say, or reporting tools for project managers. However, I don&#8217;t have one of those in mind. I&#8217;m also willing to go further afield, but again, I don&#8217;t see any prospects on the horizon.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Hunger</title>
		<link>http://www.threeriversinstitute.org/blog/?p=268&#038;cpage=1#comment-816</link>
		<dc:creator>Michael Hunger</dc:creator>
		<pubDate>Wed, 01 Jul 2009 23:47:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.threeriversinstitute.org/blog/?p=268#comment-816</guid>
		<description>I don&#039;t know if the real time collaborative editing (also possible with the online Bespin-IDE) is so helpful in pair programming. If both parties type at the same time both are focusing on their stuff and not watching what the other is doing. I think the roles of driver and navigator distribute the responsibilities quite nicely. Having different brain parts active for the two of them.
In the real world you also have just one keyboard.

What I&#039;d second is better support for pointing out things or stopping the other one doing stuff and getting into discussion/thinking. What also would be interesting is instant branching like git does but at a micro level to try out several solutions at once and see how they fit/feel/work out while keeping the current one.

But perhaps collaborative editing is attacking the wrong problem. How many developers you know really participate in pairing? How many can do it and how many want to do it. Changing the culture there is imho more important than new shiny tools.

Regarding your CAPEX discussion. Isn&#039;t that the same problem we have when being compared to the civil engineering discipline or production. That the production phase of software development is actually compiling, building and delivering the binaries? That the analysis/design effort (of production) is what we&#039;re really doing? And what is the cost of that? Its the hourly cost of the people doing the work which reflects the production costs. And this is part of CAPEX (imho) for production as it is upfront capital investment and not operational production costs. So CAPEX increases more and more? Whats the matter with artist or artisans? What are their works valued for - just the time they spend on it? Or rather the quality, the value they deliver and the reputation attached to the creator?

I think we should try to get away from the software produced anonymously by typing mokeys to product that are valued for the same reasons and that are signed by their creators. Then the value of contributions made by those recognized and recognizable people will never be zero.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t know if the real time collaborative editing (also possible with the online Bespin-IDE) is so helpful in pair programming. If both parties type at the same time both are focusing on their stuff and not watching what the other is doing. I think the roles of driver and navigator distribute the responsibilities quite nicely. Having different brain parts active for the two of them.<br />
In the real world you also have just one keyboard.</p>
<p>What I&#8217;d second is better support for pointing out things or stopping the other one doing stuff and getting into discussion/thinking. What also would be interesting is instant branching like git does but at a micro level to try out several solutions at once and see how they fit/feel/work out while keeping the current one.</p>
<p>But perhaps collaborative editing is attacking the wrong problem. How many developers you know really participate in pairing? How many can do it and how many want to do it. Changing the culture there is imho more important than new shiny tools.</p>
<p>Regarding your CAPEX discussion. Isn&#8217;t that the same problem we have when being compared to the civil engineering discipline or production. That the production phase of software development is actually compiling, building and delivering the binaries? That the analysis/design effort (of production) is what we&#8217;re really doing? And what is the cost of that? Its the hourly cost of the people doing the work which reflects the production costs. And this is part of CAPEX (imho) for production as it is upfront capital investment and not operational production costs. So CAPEX increases more and more? Whats the matter with artist or artisans? What are their works valued for &#8211; just the time they spend on it? Or rather the quality, the value they deliver and the reputation attached to the creator?</p>
<p>I think we should try to get away from the software produced anonymously by typing mokeys to product that are valued for the same reasons and that are signed by their creators. Then the value of contributions made by those recognized and recognizable people will never be zero.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeffrey Fredrick</title>
		<link>http://www.threeriversinstitute.org/blog/?p=268&#038;cpage=1#comment-815</link>
		<dc:creator>Jeffrey Fredrick</dc:creator>
		<pubDate>Wed, 01 Jul 2009 23:44:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.threeriversinstitute.org/blog/?p=268#comment-815</guid>
		<description>I happen to be reading Wealth of Nations and there&#039;s a section in there that talks addresses open source pretty clearly (though in this case it is socks). The gist is that if people who are producing a good will do so as a hobby or as a source of additional income after their supporting job that you can&#039;t compete on price.

It turns out that creating tools for developers is something that many developers are happy to do as a hobby. So the tool market for developers is a crappy place to try and make a living.

But there are lots of other markets out there.</description>
		<content:encoded><![CDATA[<p>I happen to be reading Wealth of Nations and there&#8217;s a section in there that talks addresses open source pretty clearly (though in this case it is socks). The gist is that if people who are producing a good will do so as a hobby or as a source of additional income after their supporting job that you can&#8217;t compete on price.</p>
<p>It turns out that creating tools for developers is something that many developers are happy to do as a hobby. So the tool market for developers is a crappy place to try and make a living.</p>
<p>But there are lots of other markets out there.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: KentBeck</title>
		<link>http://www.threeriversinstitute.org/blog/?p=268&#038;cpage=1#comment-814</link>
		<dc:creator>KentBeck</dc:creator>
		<pubDate>Wed, 01 Jul 2009 22:06:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.threeriversinstitute.org/blog/?p=268#comment-814</guid>
		<description>I want the experience to be as zero-touch as possible. Hence the use of GitHub as a connection point, since that&#039;s something we already do.

1. At some point we have to register somewhere. Make this as painless as possible (OpenID, Facebook Connect, whatever)
2. We each say, &quot;We&#039;re working on this GitHub project&quot;
3. Now we see each others&#039; edits in real time. It&#039;s semantically identical to sitting together and working on one machine. We&#039;re also connected by audio and/or video.

From what I understand, ECF is intended to facilitate this kind of interaction. What it doesn&#039;t seem to have is the package that puts all the pieces together. If such a package was an important goal, I would ask the team to commit to only coding using the collaborative tool environment. This would be grindingly slow at first, but I suspect it would rapidly become practical. Never underestimate the power of a frustrated geek :-)</description>
		<content:encoded><![CDATA[<p>I want the experience to be as zero-touch as possible. Hence the use of GitHub as a connection point, since that&#8217;s something we already do.</p>
<p>1. At some point we have to register somewhere. Make this as painless as possible (OpenID, Facebook Connect, whatever)<br />
2. We each say, &#8220;We&#8217;re working on this GitHub project&#8221;<br />
3. Now we see each others&#8217; edits in real time. It&#8217;s semantically identical to sitting together and working on one machine. We&#8217;re also connected by audio and/or video.</p>
<p>From what I understand, ECF is intended to facilitate this kind of interaction. What it doesn&#8217;t seem to have is the package that puts all the pieces together. If such a package was an important goal, I would ask the team to commit to only coding using the collaborative tool environment. This would be grindingly slow at first, but I suspect it would rapidly become practical. Never underestimate the power of a frustrated geek <img src='http://www.threeriversinstitute.org/blog/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Lewis</title>
		<link>http://www.threeriversinstitute.org/blog/?p=268&#038;cpage=1#comment-813</link>
		<dc:creator>Scott Lewis</dc:creator>
		<pubDate>Wed, 01 Jul 2009 20:00:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.threeriversinstitute.org/blog/?p=268#comment-813</guid>
		<description>Hi Kent,

&#039;Pair on junit&#039;...can you describe this use case a little further?  We do have some facility in ECF for sharing state information (e.g. test state) in real time (and this is used for the rt shared editing among other things), so although we don&#039;t have something finished here it might be an easy addition for yourself/someone so familiar with junit impl/internals.  Also, FWIW, there&#039;s this work on distributed OSGI testing that is now underway http://wiki.eclipse.org/Distributed_testing_framework_based_on_ECF_RFC_119_D-OSGi</description>
		<content:encoded><![CDATA[<p>Hi Kent,</p>
<p>&#8216;Pair on junit&#8217;&#8230;can you describe this use case a little further?  We do have some facility in ECF for sharing state information (e.g. test state) in real time (and this is used for the rt shared editing among other things), so although we don&#8217;t have something finished here it might be an easy addition for yourself/someone so familiar with junit impl/internals.  Also, FWIW, there&#8217;s this work on distributed OSGI testing that is now underway <a href="http://wiki.eclipse.org/Distributed_testing_framework_based_on_ECF_RFC_119_D-OSGi" rel="nofollow">http://wiki.eclipse.org/Distributed_testing_framework_based_on_ECF_RFC_119_D-OSGi</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: KentBeck</title>
		<link>http://www.threeriversinstitute.org/blog/?p=268&#038;cpage=1#comment-812</link>
		<dc:creator>KentBeck</dc:creator>
		<pubDate>Wed, 01 Jul 2009 19:40:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.threeriversinstitute.org/blog/?p=268#comment-812</guid>
		<description>Scott,

I didn&#039;t intend to diminish the efforts of ECF. I am aware of what&#039;s going on there. However, if Saff and I want to pair on JUnit, I can&#039;t pull anything out of the ECF box to let me do that. That&#039;s what I am looking for.</description>
		<content:encoded><![CDATA[<p>Scott,</p>
<p>I didn&#8217;t intend to diminish the efforts of ECF. I am aware of what&#8217;s going on there. However, if Saff and I want to pair on JUnit, I can&#8217;t pull anything out of the ECF box to let me do that. That&#8217;s what I am looking for.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
